When I apply formatting to a parent row that has multiple collapsed child rows, the default behaviour also applies the formatting to all enclosed children. I’ve noticed that when I apply formatting to a parent like this, I’m always intending to instead only apply it to the parent and find myself annoyed that I have to go back, expand the rows, re-select the parent, and only apply it there. Would be great if this default behaviour could be changed with a setting!
I’m not sure.
I see what you mean, but I’m not sure how that logic would fit in with the rest of Bike and what a selection means.
Right now formatting commands are applied to the current selection. So I think the real question is what should the current selection be understood as.
If you have a collapsed row fully selected (with also the trailing newline selected) then I “think” that should mean that the collapsed child rows are also selected. If I cut or copy in those cases I would expect everything (row and descendants) to be effected.
So one way you can work around this problem is to just make sure that you haven’t selected that trailing newline, then things should work as you expect.
… maybe
The alternative I guess is to only apply formatting to the visible selection. That makes the definition of selection more complicated, but also maybe makes some sense and maybe enabled some extra use cases.
For example, as you say, it’s not often that you want to apply formatting to a whole branch at once… so this change would get rid of that error case. And if you really did want to apply to everything you still could, you would just need to expand everything first.
This leaves me unsure. Thoughts?
Hmmm, while I feel the pull to further conceptualize what it means for an “object” to be selected in Bike, my gut is also telling me that through the lens of “user feedback”, my experience is that I’m left feeling annoyed after using that part of the tool, instead of satisfied.
Something like “making a decision with a selection, only to find out that I’ve selected much more than I had intended” feels like trying to hammer a nail and finding out that I was actually holding a prop hammer made of rubber, but now it’s happened enough times and I’m left wondering if maybe they should have designed the hammer up front to be made of metal instead of rubber. My apologies for reading one of the dumbest analogies I’ve ever written.
If I think about it, I know that Bike makes it super easy to follow through with the intention of “I want to collapse children into a parent row and move that parent around”. Though for whatever reason in my head, I think this only applies to the hierarchy levels and not hierarchy styles.
I think it might be because when I imagine selecting something with the intention of changing how it looks, I need to ultra-specifically select the amount of characters to bold/italicize, whereas if I want to change the overall indent all I need is for the cursor to be vaguely contained somewhere within the entire row. That difference in interaction granularity may be what’s causing my intuition to assume that when I’ve selected something to be bolded, it will be handled differently than when I’ve selected something to be moved.
I feel the pull to further conceptualize
Perhaps worth bearing in mind that the existing set of Bike > Format options apply standard in-line HTML semantic (rather than decorative) markup of a kind that applies within the <p> of a row.
I wonder if what you are reaching for is row types, rather than sub-string types ?
Thanks for bringing this up. I’m pretty sure that making text commands only work on visible text is the right way to go and I’ll try that approach for the next preview release. I can think of very few cases where the current behavior is needed and lots of cases where it isn’t. Also I’ve tried a few other outliners that allow selection across boundaries like Bike and they all implement formatting the way that you suggest.
I’ve changed this behavior in the latest preview release: