With read_file() revamped, it now uses partition_filestruct() indirectly
via ingraft_buffer(), so we can't use partition_filestruct() to replace
marked text in the alternate spell checker anymore without segfaulting.
Add the new function replace_marked_buffer() to accomplish this instead.
Based on replace_buffer(), it uses extract_buffer() to throw away the
marked un-spell-checked text, and then uses read_file() to insert the
spell-checked text at the position where the mark was.
Accordingly, remove unneeded partitioning and related stuff from
do_alt_speller(). Besides pasting the file into the buffer at
current[current_x], ingraft_buffer() also deals with renumbering,
updating totsize, and handling a magicline, so do_alt_speller()
doesn't need to do those anymore.
Move buffer handling and '\r' stripping from read_line() to read_file(),
so that the file gets its format determined and gets stored in its own
buffer entirely in one function. Then use ingraft_buffer() to insert
this new buffer into the current one.
In addition to pasting the file at current[current_x], ingraft_buffer()
also deals with renumbering, the updating of totsize, and the handling
of a magicline, so read_file() doesn't need to do those anymore.
Note that all this makes read_file() depend on the position of
current[current_x] to know where to insert the file. Accordingly,
set current_x to zero in initialize_buffer_text() instead of in
make_new_buffer(), so that replace_buffer() keeps working properly.
Add its explanation as a separate paragraph.
Also: improve the argument of the --syntax option, as this is a <name>
and not merely a bundle of characters like the other <str> arguments.
In this last loop of break_line(), the pointer 'line' is one step ahead
of the index 'lastblank'. So the loop should first add the length of
the preceding character to 'lastblank' before determining the length
of the current character (and using this to advance 'line').
(There is something wrong in the last loop: line is one character ahead
of lastblank, but the current character length is added to both of them.
It thus assumes that all blank characters are the same number of bytes.
For spaces and tabs this works fine. But for more exotic blanks...)
Also, rename a parameter to be less cryptic, and remove an entire
condition because the relevant block will never be reached when
getting called from the help routines: if blank_loc is negative,
the function will have bailed out in the preceding if.
In softwrap mode, the entire line is onscreen, so the word is never
partially offscreen, so we always have enough columns to show it.
This fixes https://savannah.gnu.org/bugs/?50389.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Instead of allocating enough space to convert the entire passed string,
just allocate space for converting the part that will be converted --
that is: starting from start_index. This still allocates far too much
(if the passed string is very long and its tail part won't fit on the
screen), but it's better than before.
Cap the number of pauses when displaying ALERT messages, to avoid
making the user wait for ages when tens or hundreds of files were
specified on the command line.
This fixes https://savannah.gnu.org/bugs/?50362.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When in softwrap mode, no "$" continuation characters are displayed,
so the code that reserves space for them should be skipped then.
This fixes https://savannah.gnu.org/bugs/?50335.
As a small service to the user, reject empty regex strings,
because an entirely empty regex simply doesn't make sense.
Inspired-by: Elia Geretto <elia.f.geretto@gmail.com>
When the marked region covers only a single line (or a part of it),
its new endpoint is not simply the length of the last line of the
spell-checked text, but instead the old endpoint plus the /change/
in length.
This fixes https://savannah.gnu.org/bugs/?50316.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The previous code only directly refreshed the screen when the margin
changed due to toggling line numbering on. When the margin changed
due to toggling it off, it would indirectly refresh via do_toggle().
When replacements are made, nothing needs to be reset any more
(it was done insufficiently anyway). Just make sure the screen
is refreshed when all is done -- this may be superfluous when
doing interactive replacements, but not when replacing all.
When coloring a line, look only at the multidata of the preceding
line, and based on that determine what to seek in the current line.
This fixes https://savannah.gnu.org/bugs/?50292.
When painting a line, the multidata of the line /before/ it is valid
in most cases: it was determined just a moment ago. And it tells us
all we need to know: whether there is an unpaired start match before
the current line or not.
The only exception is when painting the first line of the screen:
the multidata of the line before it might be stale. So for the
first screen line we will always have to do some backtracking.
But that is left for later.
This fixes https://savannah.gnu.org/bugs/?50121.
If we're somewhere deep into the file and do a spell check, and the
first misspelled word happens to be right there, onscreen already,
then this word does not need to be centered -- it /should/ not be
centered. We should scroll only when necessary.
After the changes to the search routine, it is no longer necessary to
take one step back before starting a replacement session.
This fixes https://savannah.gnu.org/bugs/?50147.
Even when a match falls within the marked region, this does not mean
that it is a true match when already the whole file has been searched,
because then this is the second time we find this match.
This fixes https://savannah.gnu.org/bugs/?50158.
The spell fixer does not provide a beginning line, so the search routine
should then not try to refer to any data of this line. Also, since the
changes to the search routine there is no need any more to retreat one
step before starting to search for a misspelled word.
This fixes https://savannah.gnu.org/bugs/?50159.
That is: remove the special treatment of BOW anchors, and instead make
regexes match against the whole line instead of against an artificially
shortened one, because the latter method creates ghost matches: matches
at the starting point of the search that aren't really matches when seen
in the context of the whole line.
This fixes https://savannah.gnu.org/bugs/?50030.
When the tail of a match falls outside of the marked region,
it is in fact not a match and should not be replaced.
This fixes https://savannah.gnu.org/bugs/?50136.
When a replacement happens right at where the cursor sits, the position
of the cursor should not be adjusted, because the real cursor position
is between the current character and the preceding one: the place where
the cursor is shown is in fact right /after/ the insertion point.
This fixes https://savannah.gnu.org/bugs/?50134,
and fixes https://savannah.gnu.org/bugs/?50135.
Just assign the 'CNONE' value upfront, instead of figuring out
at the end of the line whether anything has been assigned yet.
Also, the old logic would leave unmarked a line that contains a
start match without any terminating end match. Not serious, but
not right.
Don't blithely overshoot the end of a line when both start regex and
end regex match an empty string. Overshooting would let the matching
run on into uncharted country and thus ultimately cause a segfault.
This fixes https://savannah.gnu.org/bugs/?50056.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
During precalculation and in step_two, we begin looking for an end
match only after the full start match, not merely one byte beyond
its starting point. So do that too when searching backward for an
unpaired start match.
Also, index can never be zero here, because if the match was of length
zero, this piece of code will have been skipped by the preceding goto.
So we can always use REG_NOTBOL here.
(That goto is wrong, by the way: https://savannah.gnu.org/bugs/?50078,
but that will follow later.)
A search should start at the place of the cursor, not one step beyond,
so that the non-word boundary between the current character and the next
will be found. Starting one step beyond the current character, as was
done until now, would find the non-word boundary between the next and
the overnext character as the first one.
If the given line is out of range of editwinrows, we don't display it
at all, so we obviously don't display more than one line of it. Thus,
the return value in this case should be zero, not one.
(The mistake becomes visible when you go to the end of a very long line
of double-width characters: the $ will be shown on the right edge, even
though you're already at line's end.)
This reverts commit 16a7fd4b from yesterday.
When there is no end match after a start, it is pointless to look
for any more starts because also they will not have any end match,
so nothing will get painted -- just cut the loop short.
The renamed variable 'index' is not the start of a match (as some comment
mistakenly said), but from where in the line we start looking for a next
match.
Also, use one more goto to allow unindenting a big piece of code, and
shortcircuit two while loops for two more small unindents.
The setting of current_y in copy_from_filestruct() also appears to be
a holdover from the days of a more-common STATIONARY scrolling mode.
do_cut_text() uses the above function when copying text (uncutting
text again right after cutting it). Since the text is effectively
the same afterward, current_y doesn't need to change.
do_uncut_text(), however, does need current_y up to date in one case:
when uncutting a full screen or less' worth of lines, focusing will be
FALSE, and it uses edit_refresh(), so it will use STATIONARY scrolling
mode then. Take a cue from do_insertfile() and call reset_cursor() to
get an updated current_y.
(Note that the check for a full screen or less' worth of lines uses
incorrect values when in softwrap mode, but that's a separate problem.)
undo_cut(), do_redo(), and backup_lines() do not need set current_y
because they all result in edit_refresh() with focusing = TRUE, so
they do a CENTERING scroll which does not need current_y.
It is the misuse of "x_" to mean a column position on screen, and the
misuse of "_col" to mean a character position in a string that causes
this confusion.
All these different "start"s and "end"s are confusing. Use instead
'from_x and 'till_x' to remember which part of the current line is
visible now on screen and is thus represented in 'converted'.
In order to determine the correct multidata for a line that doesn't
have such data yet, the whole line must be examined, not just the
part that fits within the screen width.
This fixes https://savannah.gnu.org/bugs/?49978.
That is: only extend the current Del or Backspace undo item when the
cursor is still (or again) at the same spot.
This fixes https://savannah.gnu.org/bugs/?50006.
Instead of setting openfile->current_y (and wrongly so), just call
reset_cursor() to recompute current_y and place the cursor on that
line (if it is not offscreen).
The search routine begins searching right after the cursor and behaves
as if the line starts there, which means that a beginning-of-word anchor
(\< or \b) will match there also when in fact the cursor is sitting in
the middle of a word. To prevent finding a false match, verify that
for a regex that starts with a BOW anchor the found match is actually
the start of a word.
This fixes https://savannah.gnu.org/bugs/?45630.
Since do_mouse() uses edit_redraw(), openfile->current_y will be
immediately recalculated, so there's no point in changing it now.
Use a temporary variable instead.
The value of sameline doesn't change, so it can be initialized to that.
Since i holds openfile->current_y, it should be ssize_t, not size_t.
And it's better to do the most significant part of a calculation first.
Many of the adjustments of the value of openfile->current_y appear to be
a holdover from the days when certain functions had to account for what
is now called STATIONARY scrolling mode, which depends on the value of
current_y. Remove these adjustement where they are superfluous.
do_para_begin(), do_para_end(), and do_bracket_match() update the screen
through edit_redraw(), which uses either CENTERING or FLOWING scrolling
mode, so their setting of current_y is redundant and useless, as it will
be ignored and then overridden by the next call to reset_cursor().
findnextstr() is called by go_looking() [which calls edit_redraw(), see
above], and by do_replace_loop() and do_int_spell_fix(), which both call
edit_refresh(), which in this case only uses CENTERING scrolling mode
since focusing is TRUE.
(Additionally, the adjustments of current_y in findnextstr() and
do_bracket_match() use incorrect values when in softwrap mode.)
find_paragraph() doesn't need to save or restore current_y, because it
doesn't do any screen updates. do_justify() calls edit_refresh() with
focusing set to TRUE, so it uses the CENTERING scrolling mode.
do_alt_speller() and do_formatter() do not need to save and restore
current_y, because they don't modify it in any way.
This addresses https://savannah.gnu.org/patch/?9197.
This makes nano's cursor behavior consistent across 1) typing text by
hand; 2) pasting in text with ^U; 3) inserting text from a file; and
4) redoing with M-E that same typing or pasting or inserting.
This fixes https://savannah.gnu.org/bugs/?49968.
The warning is wrong when the user has just saved a buffer under a
new name. And when --quickblank is used, the warning most likely
gets cleared off before it is seen, and the user would just hear
the beep and be left wondering what happened.
This avoids https://savannah.gnu.org/bugs/?49875.
This disallows entering a verbatim ^J (0x0A) when typing text or
search terms, and disallows a verbatim ^@ (0x00) when typing a
filename. Nano beeps when the disallowed code is attempted.
This addresses https://savannah.gnu.org/bugs/?49897.
Also at the yes-no prompt, a 0x0A byte should be displayed as a ^J
instead of splitting the prompt bar in two and spreading it over
two lines.
This fixes https://savannah.gnu.org/bugs/?49934.
After a call to the Formatter or the Alternate spell checker, the data
on the undo stack could refer to line positions that don't exist any
more -- the chance is small, but it is there. So... throw the whole
undo stack away, to prevent undoing things wrongly or even crashing.
(Changes made with the internal spell checker can be undone and redone
without a problem -- nano keeps full track of those. But the changes
made with a formatter or an external spell checker happen in another
process, so nano has no record of them.)
This fixes https://savannah.gnu.org/bugs/?49920.
When using an external spell checker or formatter, the line with
the cursor might become shorter, which might result in the stored
cursor position being beyond the end-of-line. So, when restoring
the x position, make sure to limit it to the length of the line.
This fixes https://savannah.gnu.org/bugs/?49923.
In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.
So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar. Switch back to the default mode in the main loop.
This fixes https://savannah.gnu.org/bugs/?49893.
Decode 0x0A bytes to 0x00 when saving the search history, and encode
them again when reading the file back in, to prevent nano from hanging
or aborting when encountering 0x00 on a line by itself.
After updating the color palette, the corresponding new window content
should be drawn immediately, before some other part of the code calls
doupdate(), to prevent the old content being shown in the new colors.
This fixes https://savannah.gnu.org/bugs/?49912.
Reported-by: Mike Frysinger <vapier@gentoo.org>
In nano 2.7.1 and 2.7.2, pressing Shift+Ctrl+Arrow on a Linux console
would behave as if Shift wasn't held. It got broken three months ago,
by commit 08cd197b, messing up the proper order of the checks.
This fixes https://savannah.gnu.org/bugs/?49906.
On some systems, typing ^C apparently results in a KEY_CANCEL in
the input stream, which gets hard-bound to the do_cancel function.
But in the main menu there is no Cancel function. So... in that
case, let it fall back to the plain old Ctrl-C code: 0x03.
Reported-by: Liam Gretton <liam.gretton@leicester.ac.uk>
A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.
This fixes https://savannah.gnu.org/bugs/?49879.
So they will not break a line in the positionlog file in two.
(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)
This fixes https://savannah.gnu.org/bugs/?49877.
The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.
This fixes the second part of https://savannah.gnu.org/bugs/?49867.
Most full paths are needed only temporarily and will be freed within
milliseconds. Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session. Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.
That is: elide a second test from the most travelled path: a valid
character. This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.
The fsfromline() function is mostly used by the undo functions, which
are not present in the tiny version. It is also used by the comment/
uncomment feature, but this feature cannot be enabled when --enable-tiny
is in effect.
Convert digits() to take a ssize_t instead of an int, since it's
used on ssize_t line numbers. And properly use the long modifier
when displaying a line number.
Also, conditionalize the digits() prototype.
An added magic linefeed should be removed again /before/ restoring
the x position, as the latter needs to be calculated from the real
last line of the region.
This fixes https://savannah.gnu.org/bugs/?49817.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When wanting to debug something, it is far more useful
to temporarily insert lines like:
statusline(ALERT, "name = %i", variable);
It provides instant feedback, and it slows things down,
so you can kind of see what happens.
The functions read() and fwrite() take size_t, not ssize_t.
And line numbers in the file should be displayed as a long type instead
of an int, since the effective type of ssize_t is not int, but long.
(The variable 'pletion_line' is not conditionalized with this option, as
it would become messy. The compiler will probably be able to elide it.)
When using --enable-tiny, it is not possible to use --enable-wordcomp,
because the word completion function uses the undo system.
Executing the 'complete_a_word' function will search from the start
of the current buffer for entire words that begin with the fragment
that is before the cursor, and will complete this fragment to the
first word that is found. Each consecutive call of 'complete_a_word'
will search for the next matching word and will complete the fragment
to that. By default the function is bound to the ^] keystroke.
Signed-off-by: Sumedh Pendurkar <sumedh.pendurkar@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Modern VTE-based terminals now produce codes for those keys and
no longer swallow them when nano is active.
This addresses https://savannah.gnu.org/bugs/?49746.
Achieve this by reusing the code that gives feedback when trying to
save a buffer while using --tempfile and the file has no name yet.
This fixes https://savannah.gnu.org/bugs/?48622.
Also for Delete, End, PageUp and PageDown (on some terminals)
the last byte in the sequence needs to be checked.
This fixes https://savannah.gnu.org/bugs/?49710.
If it would, the returned file descriptor would make nano crash,
because the corresponding stream has not been opened. And when
returning zero instead (as the code did originally), nano would
open an empty buffer, although it claims to be reading the file.
In short: I think this is a leftover of an attempted fix of
https://savannah.gnu.org/bugs/?25297, from commit 2823c99.
David Lawrence Ramsey