[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: <Tab> is not captured while selecting

From: Benno Schulenberg
Subject: Re: <Tab> is not captured while selecting
Date: Tue, 3 Dec 2019 17:24:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

>> 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


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]