A file is always in either Unix or DOS or Mac format, and should
by default be saved again in that same format.
Any lone CRs or LFs after the first line should not change the
format that was deduced from that very first line.
Only when a CR is seen before any LF, and the CR is not followed
by a LF, should this CR be interpreted as a line separator. And
only then the file should be reported as being in Mac format --
as long as --noconvert is not used.
This fixes https://savannah.gnu.org/bugs/?58357.
Bug existed since at least version 2.0.6.
Also, when finish() is called when the user presses Cancel upon
encountering a lock file, there is no need to save any history
files because nothing has changed.
When the user mentions the file "zzy" on the command line,
the magic spell "Xyzzy" does not actually get typed, so the
Easter egg should then not be triggered.
This will not catch all cases, but at least it will precalculate the
data when syntax coloring was toggled off (M-Y) while in one buffer
and then toggled back on after having switched to a new buffer.
When a file is saved under a different name, and as a result the
applicable syntax changes, and the old syntax had multiline regexes
and the new syntax doesn't, then the call of precalc_multicolorinfo()
in write_file() should not result in nano setting up a multicache of
zero bytes for each line in the buffer.
(Problem was found by locally letting nano crash when zero bytes are
allocated, and then happening to rename a file.py to a file.sh.)
A long option should describe what it does, not vaguely hint at it.
Also, in several places of nano's code we deal with actual temp files,
and then having a flag called TEMP_FILE that doesn't have anything to
do with temp files is somewhat confusing.
Just let all anchors disappear when doing an external spell check or
formatting or piping the buffer through an external command, because
leaving just a single anchor on the top line is useless.
This fixes https://savannah.gnu.org/bugs/?58273.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When a single paragraph is justified, any anchor on any of its lines
gets moved to its first line. Let a full justification do the same
for each of the paragraphs.
This fixes https://savannah.gnu.org/bugs/?58272 in a better way.
This fixes https://savannah.gnu.org/bugs/?58272.
Bug existed since commit 732cf887 from one month ago. That code
causes an anchor to persist at the point where lines are removed.
When set_colorpairs() is called, no files have been loaded yet, so
no syntaxes will have been loaded yet either. Thus it is pointless
to run through the list of available syntaxes.
Its major function is to find an applicable syntax, if there is any.
And if the syntax hasn't been used before, to prime its color pairs.
Also, reshuffle a line to be able to elide an #ifdef.
In "Cut Text" and "Paste Text" the word "Text" is superfluous. (It
could even be called slightly misleading, because by default ^K will
cut the current line, whether or not it contains text.)
The "Get Help" is of course inherited from Pico, but to me it has
always sounded a bit as if it would go search help on the internet.
Instead of "Spelling" I would have preferred "Spellcheck", but that
gets a bit too cramped on an 80-column terminal.
For ^C I've chosen "Location" because I tend to understand "Position"
as a verb, especially when seen next to "Go To Line" (even when having
two items with the same meaning next to each other doesn't make sense).
"Mark Text" has simply always been wrong. It doesn't mark anything,
but just *sets* the mark (or unsets it, but that normally happens
automatically, no need to mention that in the label).
The "Cut Till End" and "Full Justify" get shown only on very wide
terminals, and at such widths there is enough room for each label
to write out those two labels in full.
Fortran and POV-Ray files are not found on any regular install of a
Unixy system nor in common software packages. People who want these
syntaxes will have to make a little effort to enable them.
Also, do not colorize the text between two stricken-through words,
do not colorize text immediately after an indented piece of code,
but do give color to a double trailing space.
Signed-off-by: Ryan Westlund <rlwestlund@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Benno Schulenberg