nano-devel
[Top][All Lists]
Advanced

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

Re: how to represent the TAB key status


From: Benno Schulenberg
Subject: Re: how to represent the TAB key status
Date: Sun, 27 Dec 2020 17:21:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Op 26-12-2020 om 09:06 schreef ObeliX:
> On 24.12.20 14:44, Benno Schulenberg wrote:
>> When Alt+O is toggled... well I think it should show an "O",
>> because that is what the other toggles (Alt+I, Alt+L, and Alt+S) do.
> 
> hmm, I think the visual representation of a flag should be associated to
> the function itself, not to the shortkey used to toggle or change it.
> "O" would be counterintuitive for a TAB-setting.

I agree with that -- I wasn't entirely serious when I proposed using "O"
to indicate that <Tab> will enter spaces.  :)  Even though it would be
the logical thing to do.

> if you are unfamiliar
> with nano you don't know that M-O is the default shortkey to toggle it.

But a fresh user won't know the toggle for auto-indent and hard-wrapping
either, so that is hardly an argument against using "O".

> how about to use the center-dot "·", that is generally used by editors
> (including nano) to represent space characters in show-whitespaces mode?

Nah...  It's just as obscure as "O" but without the benefit of indicating
how to toggle it off (by default).  Also, it seems to indicate a single
space, whereas <Tab> will most likely enter multiple spaces.

> if that is not to your liking, I support Peters suggestion of using a
> lower-case "s" (even that 'softwrap' already uses the upper-case "S").

Yes, that might be the best option.

>> When 'tabgives' is active, it could show a "t" when the first character
>> in the tabgives string is a tab, an "s" when it is a space, and an "x"
>> otherwise.  But I'm open to better suggestions.
> 
> the idea for the TAB-flag was to indicate to the user what he gets when
> hitting the TAB-key, not to precisely disclose the configuration

(Sure.  But when "s" and "t" were not used for indicating the state of the
'tabstospaces' toggle, then they could be used to indicate extra info.)

> if the tab
> character comes from the TAB-key itself or from the tabgives string,
> does not matter to the user.

But it does.  When tabgives is active, the M-O toggle will not have any
effect.  To prevent the user from hitting M-O to turn 'tabstospaces' on
when seeing "T" in the state flags, and then wondering why it doesn't work
("Did I rebind the key? Why isn't it toggling?"), it must be so that whenever
'tabgives' is active it must be clear from the state flags.

> only the special case were the tabgives string is set to nothing, got an
> additional flag symbol, so the user is able to see, that it's not a
> broken TAB-key on his keyboard, why nothing happens when hitting that key.

I don't see why this needs special treatment.  Can you give any example
of a syntax where it would be useful to disable the <Tab> key?


Anyway...  I (reluctantly) propose the following:

  " "  :  <Tab> produces \t  (the normal, default situation)
  "s"  :  <Tab> will enter the relevant number of spaces
  "g"  :  'tabgives' is active, <Tab> will give whatever was given there


> if there is a rule, I could not deduct it. but I'm happy to hear about
> it, for future occasions.

The rule is: when making a patch, don't change anything that doesn't *need*
to be changed.  If you can avoid changing a line, avoid it.

> just appending the additional condition would have made the second line
> quite long. thus it seemed a good idea to introduce a third line for the
> if statement anyway.

Then you could have added just that new condition on the inserted line:
it would have avoided changing both the first and the second line.  Don't
worry about ugliness, it can be adjusted later: I do that all the time in
the "tweaks" commits.  When adding new code, format it properly and cleanly.
But when changing existing code, change as little as possible, so that it
is easy to see /what/ is changed.

> when I mentioned in an earlier post, that I don't understand why there
> is a 7 character long placeholder for the 5 state flags, you told me not
> to fiddle with that code.

That was for a specific reason: there was a code change in the pipeline
that I didn't want to have to rebase.

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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