I never, ever use column selection or typing, so perhaps the following behavior is useful there.
Frequently I have a block of code I need to indent. Say my Ruby code looks like this:
class Foo def bar puts "yay" end end
I lazily select parts of the lines I want, (because it's faster than being sure to select the entire line) represented by the | in the following showing the start and end of the selection:
class Foo de|f bar puts "yay" en|d end
When I press cmd-], I expect:
class Foo def bar puts "yay" end end
(which is what BBEdit gives me), but what I get is:
class Foo de f bar puts "yay" end end
...where's the logic in that? If I have no text selected, but the carat is in the middle of the line, cmd-] shifts the whole line (as desired). I suggest that the 'break-the-line' method only occur if the selection is columnar - i.e. if the start column of later lines is the same as the start column of the first line.
On 07/09/2005, at 6.47, Gavin Kistner wrote:
I lazily select parts of the lines I want, (because it's faster than being sure to select the entire line) represented by the | in the following showing the start and end of the selection:
What you can do is do you lazy selection, then:
1) automation / start macro recording 2) edit / select / hard lines 3) shift right
Now save that on cmd-] and you have effectively redefined the function to what you prefer.
On Sep 7, 2005, at 2:33 AM, Allan Odgaard wrote:
What you can do is do you lazy selection, then:
- automation / start macro recording
- edit / select / hard lines
- shift right
Now save that on cmd-] and you have effectively redefined the function to what you prefer.
That's a reasonable workaround. Thanks. Is there an argument/use case for the current behavior when non-columnar text is selected?
What you can do is do you lazy selection, then:
- automation / start macro recording
- edit / select / hard lines
- shift right
Now save that on cmd-] and you have effectively redefined the function to what you prefer.
Man, I learn more useful stuff from this list... The signal-to-noise here is quite high.
Thanks Allan, as always.