Re: <Tab> is not captured while selecting

[Benno Schulenberg]

>> We could change the rule so that <Tab> only means 'indent' when the cursor is
>> on a different line than the mark.  This would preserve the intention of the
>> function (to be able to indent a group of lines as a whole), without
>> interfering with your foresight selecting -- well: unless you type multiple
>> lines, including Tabs, while the mark is on. Is there any chance you would do
>> the latter?
> 
> Yes, that would do the trick for me.

Okay, then that is what I will push, in a few days.  In the bargain, it
brings the behavior of this feature in nano closer to how it behaves in
editors like Gedit and Geany and Kate: also there <Tab> only works as an
indentor when beginning and end of the selection are on different lines
-- I noticed today, after taking a closer look at them.

> But perhaps there is another way to look at this:
> 
> * Selection is started.
> 
> * If a key is pressed before the selection is closed, then insert the
>   symbol, even if it is <Tab>. That's what users expect.
> 
> * Once the selection is closed, a <Tab> shifts to the right all the lines
>   of which at least a part has been selected.
> 
> In other words: act only once a selection is complete.

Ehm...  How is nano to know when a selection is "closed" or complete?
You mean, when the mark is switched off again?  That would be weird:
<Tab> would move a bunch of lines that are not visually marked in any
way.

Benno

signature.asc
Description: OpenPGP digital signature