The first_sc_for() function is somewhat costly, so avoid calling it
when it is not necessary.
Most menus have either so many entries that unbinding some keys does
not reduce the number of shown entries, or they have so few entries
that each entry already has space enough and will not profit from
having more room available. But the WriteOut menu is an edge case.
Most translators don't use --tempfile and translate the key tags for
the WriteOut menu making use of all 17 positions that are available
for each of them. This makes that when --tempfile is used, some of
those tags get truncated. This is not so bad, because --tempfile is
normally not used. But when it isn't used (when the discardbuffer
function isn't bound), the WriteOut menu should make full use of the
available width to avoid truncating any translated tags.
In this way the keycode cannot be unbound from the 'indent' function,
so pressing <Tab> on a marked region will always indent the region.
This fixes https://savannah.gnu.org/bugs/?56960.
Bug existed since the "tabbing" of a marked region was introduced,
in version 2.9.2, commit 09958ebd.
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>
As printf() is not UTF8-aware, we have to determine ourselves how many
columns each short and long flag take up and add the required number of
spaces (not tabs, because their size is not fixed) to fill things up.
This fixes https://savannah.gnu.org/bugs/?56928.
Bug existed since version 4.3, commit 2f169107.
When the user specified an absolute path... it is NOT relative to the
current working directory.
This fixes https://savannah.gnu.org/bugs/?56902.
Reported-by: Brand Huntsman <alpha@qzx.com>
Bug existed since version 2.4.2, commit ec8d51be.
For a forward search from the command line, pass FALSE to 'skipone'
so that an occurrence at the head of the file is not skipped over.
This fixes https://savannah.gnu.org/bugs/?56845.
Reported-by: Derek Wolfe <dwwolfe1@gmail.com>
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The regcomp() function from glibc-2.27 (and older) considers the
bracket expression ['-.] to be invalid -- mistakenly. Avoid using
any range expression in the relevant regex and instead enumerate
all acceptable characters.
This avoids https://savannah.gnu.org/bugs/?56766.
Allow the user to specify that the search string should be interpreted
case-sensitively and/or as a regular expression by preceding the search
indicator (/ or ?) with c and/or r. Or to switch these things off by
using C and/or R.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The string to "jump to" is specified with +/ for a forward search
(from the top of the file), or with +? for a backward search (from
the bottom of the file).
This fulfills https://savannah.gnu.org/bugs/?54535.
Requested-by: Derek Wolfe <dwwolfe1@gmail.com>
With-help-from: Brand Huntsman <alpha@qzx.com>
Benno Schulenberg