Texinfo-6.8 (that was used to build the docs of nano-5.9) changed
the way the @contents command is processed for HTML output, with as
result a detailed table of contents at the start of the HTML page.
That is ugly and too much detail. To avoid that, produce a table
of contents only when generating output meant for printing.
This fixes https://savannah.gnu.org/bugs/?61344.
Bug existed since version 5.9.
What @* does is guesswork when you don't use Texinfo regularly.
That the "sp" in the @sp command refers to vertical space is not
very clear either, but the command is used on nearby lines too,
so better use it more.
Also, improve two wordings and fix a four-year old typo.
An @command must either start at the beginning of the line and be
followed by whitespace or EOL, or it must be followed by a brace.
Colorizing just any "@text" string colored too much.
Also, allow an @} and another @command{} within a pair of braces,
colorize only the valid @-commands with uppercase in their names,
unbold enclosed command arguments, colorize the directory entries
for the manual, and properly colorize also the comments that use
the full @comment command.
Reference:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Command-List.html
Testing was done with:
info texinfo @-C "Command List" --output=list
sed -i -e "s/^'//" -e "s/'$//" list
nano list -Ytexinfo
In olden times, each help text started with a title line in the text
window followed by a blank line. But since version 2.8.2, since the
help texts have become almost regular buffers (and thus searchable),
the title of the help text is in the title bar, and since version 4.0,
since --morespace became the default, the text will start immediately
below it. But a title line immediately followed by text, without a
blank line between them, does not look nice. So, add such a blank
line back when not using --emptyline (and also when using --minibar,
because the top of the terminal window is like a title bar).
When the history file has been created by nano, it will not contain
any duplicate search or replace strings, nor duplicate commands, so
checking for such a duplicate for each read item was a waste of time.
And if the user edited the history file and created duplicates, who
are we to filter them out? They will not cause the history mechanism
to malfunction; they just take a little extra memory.
(Aaah, being able to define a keyboard macro
came in very handy when making this edit.)
This fixes https://savannah.gnu.org/bugs/?61331.
Bug existed since before version 2.2.0.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
When the user immediately cancels a search (^W^C), then nothing in
the history stack has changed, so then there is no need to reset the
history pointer to the bottom.
This slightly improves the fix for https://savannah.gnu.org/bugs/?61316.
This also gets rid of an assignment in an 'if' clause (twice),
elides a local variable, and makes it clearer that a pointer
gets moved to the previous or next item (instead of hiding it
as a side effect of the function call).
Whenever invoking a search prompt, calling up historical search items
should start with the newest item.
This fixes https://savannah.gnu.org/bugs/?61316.
Bug existed since version 2.8.2, since help texts became searchable.
When the answer at the prompt was clear before the user went up into
the history list, the answer should be cleared again when the user
comes back down to the present.
This fixes https://savannah.gnu.org/bugs/?61308.
Bug existed since before version 2.2.0.
For consistency, these five names ought to start with "flip_", but
then the bindable functions would need to be renamed too, and that
would be annoying for the user, *and* it would create too many names
that start with "flip" -- it wouldn't be distinctive any more.
When the current filename is equal to the filename of the buffer,
then clear the filename, because the chances that the user wants
to append or prepend a file to itself are practically nil.
This fulfills https://savannah.gnu.org/bugs/?61243.
The keystrokes are not listed, but should work like
they do in a normal, editable buffer.
This fixes https://savannah.gnu.org/bugs/?61274.
Bug existed since version 4.0, commit bc98dbca.
The functions to_first_file() and to_last_file() can get called from
do_statusbar_input(), which is called indirectly from do_prompt(),
and are expected to make the corresponding adjustment.
This fixes https://savannah.gnu.org/bugs/?61273.
Bug existed since version 5.0, commit 07c1ac90.
Some Yaml files use path names and sometimes version numbers as keys,
even though / and . are not officially in the character set allowed
for key names (just like underscore is not), as far as I understand.
Also, do not colorize any backslash escapes as invalid
because some of them occur sometimes in value strings.
Also, colorize only the valid double-exclamation tags.
This avoids an unused and misleading assignment that might make
someone think the incremented variable will be used again.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Perl keys can contain a double colon. And unspaced colons occur
quite regularly in values (URLs, IPv6 addresses, and the like)
and should not be colored as if they were an error.
The calls of write_file() in do_spell() and do_formatter() write out
a temporary file -- such a file does not have an 'openfile' record,
so setting 'annotate' to TRUE was pointless. Using the correct value
for this parameter allows dropping two conditions in write_file().
And when 'exiting' is TRUE and --save-on-exit is in effect, it is
slightly wasteful to stat() the written file and store the info in
its 'openfile' record as the buffer will be closed directly after.
So, now the only place where 'annotate' is TRUE is when writing out
the full buffer to a normally named file.
