Re: how to represent the TAB key status

[ObeliX]

On 27.12.20 17:21, Benno Schulenberg wrote:
> Op 26-12-2020 om 09:06 schreef ObeliX:
> > 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.
> > [...]
> > 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".

it is, I think. as I said, the flag's symbol main purpose is to give a
clue for the function it represents, not to its shortcut. even a fresh
user has a fair chance to correctly assume that "I" has to do with
Indention and "W" with the Wrapping of the text. for "O" --> tab mode,
ähm ... you definitely have to read the manual. ;)

> > how about to use the center-dot "·", that is generally used by editors
> > (including nano) to represent space characters in show-whitespaces mode?
>
> Nah... > [...]
> Also, it seems to indicate a single > space, whereas <Tab> will most likely 
> enter multiple spaces.

I don't see the danger, that anybody sees this as a literal
representation of the tab character. but looks like that the "s" is
winning the election anyway. ;)

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

OK, I see, that's a good point.

maybe we can have the same flag for TAB=='\t' regardless if default tab
mode or 'tabegives' is active AND save the user from wondering in a
consistent way. how about, giving textual feedback in the status line
when user tries to toggle tab mode when 'tabgives' is active. in
non-tabgives mode, toggling 'tabstospaces' already displays a feedback,
letting the user to know, if 'tabstospaces' was switched on or off. in
'tabgives' mode, it could say something like "can't alter tab mode - is
set by syntax rules for this buffer".

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

no, I can't.

but "" is a valid setting for 'tabgives' and it could cause user
confusion. and as it is easy to catch this situation, I thought it does
not hurt to handle it on its own. so, I don't have a special hold to it.
if you think, it's not worth an own flag symbol, I'm totally fine with that.

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

with "could not deduct a rule" I meant the depth of indentation for the
second line of the if conditions in that specific case, not a general
'how to modify'.

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

yes, I already understood that the first time.

I mentioned the stateflag placeholder a second time, in the hope you
would explain this time WHY the placeholder is two characters longer
than the actual stateflags are. because (at least currently) the only
purpose for the placeholder is to define the length of the stateflag string.


MfG Obel