The word "fixer" sounds too much as if the command would be able
to fix mistakes or correct errors. Especially when seen next to
"linter", it sounds as if one does a syntax check and the other
fixes the found mistakes. (Although the command might in theory
be used for this, it is not its intended purpose.)
Nowhere does the manual say that nanorc keywords are case-insensitive,
and none of the examples use uppercase keywords. So, simply consider
uppercase keywords to be invalid. This will later allow nano to use
case-sensitive comparisons, which are slightly faster.
For historical reasons the rebinding code allows binding F13...F16,
which on most terminals are typable with Shift plus F1...F4. But,
at least on an Xfce Terminal, Shift plus F1...F12 produce F13...F24.
On a Linux console, Shift plus F1...F8 produce F13...F20. So: allow
to bind the full shifted F13...F24 range. It costs no extra code
and makes things more rounded.
The 'tabgives' command is syntax-specific and should be followed by a
string containing the character(s) that a single press of the <Tab> key
should produce -- most likely a single TAB or a small bunch of spaces,
but any string is allowed. This overrides the 'tabstospaces' option.
When one wants to make sure <Tab> inserts always four spaces and never
a TAB when editing a Python file, one could add to one's nanorc:
extendsyntax python tabgives " "
where there are four spaces between the quotes. And when one wants
to ensure, when editing a Makefile, that <Tab> always inserts a TAB
and never spaces, independent of what tabstospaces is set to, one
could add to one's nanorc:
extendsyntax makefile tabgives " "
where there is a literal TAB character between the quotes.
This fulfills https://savannah.gnu.org/bugs/?53661,
Requested-by: Andrew Pennebaker <andrew.pennebaker@gmail.com>
And addresses https://savannah.gnu.org/bugs/?54760.
Requested-by: Henry van Megen <hvanmegen@gmail.com>
And addresses part of https://savannah.gnu.org/bugs/?54775.
Requested-by: Dirkjan Ochtman <dirkjan@ochtman.nl>
Using --zap or -Z on the command line, or 'set zap' in a nanorc file,
makes the <Bsp> and <Del> keys erase selected text (a marked region)
as they do in some other editors, and without affecting the cutbuffer.
This fulfills https://savannah.gnu.org/bugs/?54837.
Requested-by: Liu Hao <lh_mouse@126.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
When 'afterends' is set and Ctrl+Right or Shift+Ctrl+Right is pressed,
nano will stop at the ends of words instead of their beginnings.
Signed-off-by: Mark-Weston <markweston@cock.li>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
It's better to color some invalid things as if valid than the other
way around. So, as strings can validly contain any number of double
quotes, just accept *anything* between the delimiting double quotes
and demand that the closing quote is followed by whitespace or EOL.
The new option 'set selectedcolor' applies to marked text, to the
currently selected file in the file browser, and to the highlighted
match during interactive search-and-replace.
Extend get_softwrap_breakpoint() to break softwrapped lines on
whitespace when a flag is set. This flag is controlled by the new
rcfile option "atblanks". The '>' characters marking two-column
characters at the edge of the screen are disabled when it's on.
If get_softwrap_breakpoint() can't find whitespace in screen range, it
will break the line on the screen edge. (In this case, a blank can be
on the last column of the screen, but text can't, so that a blank on the
last column doesn't become invisible and possibly break the display.)
This fulfills https://savannah.gnu.org/bugs/index.php?49959.
Requested-by: Nicholas Boel <axxisd@gmail.com>
Negative arguments of 'fill' are bright green since a few commits.
So now color all valid numeric arguments in that same style -- the
yellow was hard to see on a dark background anyway.
Also, color a zero tabsize as invalid.
Benno Schulenberg