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: Mon, 28 Dec 2020 17:24:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Op 28-12-2020 om 07:08 schreef ObeliX:
> 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.

There is no "W" in the state flags.

But true, also "L" can (with some thinking) be understood as referring
to breaking Long Lines.  But the good thing about "I" and "L" and "S"
is that they echo the corresponding toggles.  It would be strange if
the 'tabstospaces' flag were the odd one out.

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

I don't see the advantage of showing " " instead of "g" in the state flags
when tabgives is exactly a \t.  On the contrary, I think it's better to
clearly indicate that the current syntax forces the behavior of the <Tab>
key.  What that behavior then is, is not really relevant, as the user will
have defined it herself, as none of the included syntaxes uses 'tabgives'.

> but "" is a valid setting for 'tabgives' and it could cause user
> confusion.

Which would be self-induced.

> and as it is easy to catch this situation,

Maybe the rcfile routines should forbid setting 'tabgives' to an empty
string.  Because now, when putting «extendsyntax default tabgives ""»
in my ~/.nanorc file, and then typing <Tab> in the README file, the
buffer gets marked as modified even though nothing changed.  That is
not right.  So something should be done about that.  (But it's nice
that Undo and Redo handle this edge case just fine -- no crash.)

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

I know.  But you annoyed me with saying that you /had/ modified a line
when obviously you hadn't -- whitespace changes are /not/ changes -- so
I wiped that whole text.

There is no rule.  The indentation of continuation lines are whatever
pleases me esthetically.  Do not bother with those, do not change them.

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

When you have questions, it's better to ask them directly, instead of
hoping that I will read between the lines.  :)

The stateflags placeholder "+.xxxxx" does not just cover the five
state flags (x) but also the modification asterisk (+), plus a space
(.) to separate the two things.  This is needed to avoid the asterisk
and the state flags from overwriting each other.

Run for example: nano -IbiS% somefile, type xx to modify the buffer,
and then make your terminal narrower and narrower.  Watch how the
stuff in the title bar behaves.

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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