For a little contrast with the function edit_refresh() -- it's
annoying that when you search for the latter you get to see all
the settings of the flag too.
The function edit_update() is called by edit_refresh() itself, so it is
silly that the first sets 'edit_refresh_needed' to TRUE. This setting
is needed only in a few cases -- in the others it's not needed because
the screen does not need to be refreshed (it was just about positioning
the cursor), or 'edit_refresh_needed' has already been set by a call to
goto_line_posx(). So, just set the flag in the five places that need it
and spare the other four calls.
Since commit 41ed690, cancelling a prompt after tabbing would sometimes
leave the list of file names on the screen. When testing this first,
it worked fine -- I was fooled again by 'edit_refresh_needed' already
being TRUE when nano has just started up and sits waiting for the first
key stroke. I have to hunt this down and kill it.
Since commit dac0aa1, nano would leave edittop at current after reading
data from standard input, meaning that everything that had been read in
was invisible, "scrolled off" the top of the screen. Correct this by
explicitly setting edittop.
The above does not happen for ^R (^X) because it has a special mechanism
to save and restore edittop. Nor does it happen for ^R ^X M-F because it
sets current to the top of the file and refreshing the screen will make
edittop follow, or -- in case just one unterminated line was read in --
edittop will already be equal to current.
A normal lock file is apparently 1024 bytes in size, so the second
attempt at reading bytes from the file would try to read 8192 more
bytes into a buffer that has room for only 7168 left. According to
valgrind, the read() function doesn't like that -- and true: if for
some reason the lock file had suddenly expanded, the buffer would
overflow.
This fixes https://savannah.gnu.org/bugs/?47156.
Commit 36ec76a made the wrong change: after a tab that did not list any
file names on the screen, a refresh /is/ needed, because a previous tab
might have listed things on the screen. But at the end of the prompt,
it is not necessary to refresh the edit window if things were listed,
because the window will be refreshed anyway after reading in a file.
Use 'slash' to point at a possible slash, use 'filename' just to
point at the real file name, and use 'wasdirname' just to point at
the dir's name before expanding it in order to be able to free it.
Also, remove two superfluous asserts: 'dirname' cannot be NULL
because it has just been mallocstrcpy'd, and checking 'num_matches'
is pointless as it would crash on the next statement anyway.
This is a remnant from 2001, when things were different. Now, there
is no need to refresh the edit window when tabbing produced no list.
When it did produce a list, it is cleared off later.
If for some reason opening the spell-checked or formatted file fails,
don't throw away the current contents of the buffer.
(It should also give proper feedback about the failure, but we'll leave
that for some other time.)
Also, store the input character earlier, so we don't have to use len - 1.
Furthermore, len increments in steps of 1, so it cannot pass the value of
bufx unnoticed, so use a comparison for equality.
Most of the time NO_CONVERT will not be set, the number of lines will
not be zero, and the format of the file will be zero. Rearrange the
conditions so that they will evaluate as FALSE as soon as possible.
Index i follows almost synchronously the value of len. Since we're
adding characters to the intermediate buffer always only at the end,
just use len as the index.
Until now (when not leaving files unconverted), nano would fumble and
drop the final carriage return of a Mac file, and would thus treat the
last line of such a file as an unterminated line and prepend it to the
current line of the buffer. Correct that, and delete the dead piece
of code that was meant to do this.
This fixes https://savannah.gnu.org/bugs/?47716.
When we don't set edittop in read_line(), we don't need to readjust it in
read_file(), because in that particular case it will still be pointing at
current. And since fileptr is a new, freshly created line, it can never
be equal to filebot, so there is no point in comparing them.
If more than one line was inserted at the beginning of the file, leave it
up to the screen handling to set edittop to what it should be.
Move the setting of fileage a bit down, to its sister setting: the line
at current gets "connected" either to the top-of-file pointer or to the
last line of the inserted file.
The number of lines to scroll is: the y position of the start of the
current line, plus the extra lines that this line occupies, plus the
extra lines that the next line occupies, plus one, minus the y position
of the last window line.
The y position of the start of the current line is current_y -
xplustabs() / COLS, the extra lines are strlenpt(data) / COLS,
and the y position of the last window line is editwinrows - 1.
Note that we first compute the amount to scroll before actually moving
to the next line, because we need the current value of current_x, not
the one that it will have in the next line. The placewewant value is
not good either, because it might be beyond where we actually are.
This fixes https://savannah.gnu.org/bugs/?47665.
(This change will be made superfluous when we start using gnulib.)
This prevents getcwd() from failing on Android and thus completes the
fix for https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Doing a chdir("..") will not fail when the root directory is reached,
and when getcwd() keeps failing too, we have no way of knowing when
to stop. So, simply limit the number of attempted chdirs, to avoid
getting into an endless loop.
This avoids the hang in https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Also, don't force a full refresh of the edit window simply because the
current line needs to be horizontally scrolled. And further, when the
adjustment of edittop has determined that a full refresh is needed,
get out and don't bother scrolling some lines first.
When in softwrap mode and scrolling down a line, and thus going to
do a full refresh, get out and don't bother redrawing the current
and prior lines first.
When moving the cursor up or down one line, redraw the new current
line only when the target column (placewewant) is beyond the screen,
or when the mark is on.
(This still redraws the current and prior lines unnecessarily when
they are in fact shorter than the screen is wide and the mark is off,
but we'll let that pass for now.)
Also, when softwrap is on, we don't have have to redraw the current
and prior lines at all (when the mark is off): they are in full view,
there is nothing to show or hide.
When scrolling down a line, a full refresh of the edit window is only
needed when softwrap is on, because only then the movement is irregular.
When each file line takes up just one screen line (softwrap is off),
edit_scroll() is perfectly able to scroll and redraw only the necessary
lines.
(But... when doing a full refresh anyway with softwrap, why bother
scrolling at all? Why not just adjust edittop and call refresh?)
The old_current line needs to be redrawn only if it differs from current,
and if it wasn't drawn already by the iteration for when the mark is on.
Also make the conditions involving horizontal scrolling more precise.
Instead of saving the current value of placewewant, then setting the
new value, and then passing the old value to edit_redraw() in seven
different places, just let edit_redraw() do this saving and setting.
In the bargain placewewant is now only recalculated when it matters
-- when allow_update is TRUE -- and not when it's superfluous.
Nano doesn't start doing anything with the edit window or the keyboard
until all files have been read in or a blank buffer has been opened, so
the case of openfile->current == NULL will never occur.
Also correct the comment -- because with multibyte characters, it is
very well possible that the screen column corresponding to current_x
is smaller than current_x itself.
Instead of allocating a fixed amount of 128 bytes, which will overflow
and segfault, adjust the allocation to the length of the file name, and
if necessary trim the file name to make the prompt fit on the screen.
This fixes https://savannah.gnu.org/bugs/?47511.
Reported-by: Aapo Rantalainen <aapo.rantalainen@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
In the innermost search loop, don't set placewewant, because this loop
is also used for replacing and spell fixing, when we don't really want
to be there: we are just passing through. Not setting placewewant means
we don't need to save and restore it in those passing-through routines.
The value of placewewant is only relevant when doing cursor movement,
which doesn't happen during replacing nor spell checking, so there is
no need to keep placewewant up to date -- it is set when it matters:
at the end of go_looking().
Stop keeping track of the vertical screen position when searching for
something. If nothing is found, current_y doesn't change, and all the
incrementing/decrementing was a waste of time. If something is found
and it is onscreen, it is easy to calculate the new current_y. And if
something is found and it is offscreen, then current_y is irrelevant,
because we will be either centering the found occurrence (searching)
or putting it on the top or bottom line (bracket matching).
(The above does not take softwrapping into account, but neither did
the old code, so this doesn't introduce any new bugs.)
(Also, when the search wraps, and the viewport is away from head or
tail of the file, and the found occurrence is within the viewport,
then the incremented/decremented current_y would be way wrong, but
this didn't have any adverse effects as far as I could tell. It
seems that current_y is irrelevant in most cases.)
Add a third mode of scrolling, FLOWING, besides CENTERING and STATIONARY.
This is used for word and paragraph jumping (and for bracket matching,
but that worked correctly already), and only when focusing is FALSE.
The new mode prevents the screen from scrolling too many lines when
there are several blank lines at the bottom of the edit window and
the next word or paragraph is out of view.
This fixes https://savannah.gnu.org/bugs/?47194.
On iTerm2 on OS X, the Option+Arrow keys produce special sequences
that start with two escapes. Catch these sequences and interpret
them appropriately as WordLeft / WordRight / Home / End.
Signed-off-by: Mike Scalora <mike@scalora.org>
Signed-off-by: Thomas Rosenau <thomasr@fantasymail.de>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Benno Schulenberg