The new function, update_softwrapped_line(), is called from inside
update_line() when softwrap mode is on, so that existing calls remain
unchanged. It takes no index, instead displaying edittop from column
firstcolumn, and all other lines from column zero.
If current is on edittop, it's displayed using the edittop rules, but
this is not a problem: if current[current_x] is above edittop at column
firstcolumn, it's offscreen, and that should be handled before calling
update_line() anyway.
Together with the preceding bunch of changes,
this fixes https://savannah.gnu.org/bugs/?47667.
Make current_is_above_screen() check for current[current_x] being above
edittop at column firstcolumn, and make current_is_below_screen() start
counting down from edittop at column firstcolumn instead of edittop at
column zero. This means that both functions now account for softwrapped
chunks properly.
Actually enable scrolling edittop partially off the screen by making
edit_scroll() and adjust_viewport() use firstcolumn properly when
iterating through softwrapped chunks in softwrap mode, or lines in
non-softwrap mode.
In non-softwrap mode, firstcolumn should still always be zero, because
it's initially set to that, and because passing it through the iterators
will maintain it at that.
This fixes https://savannah.gnu.org/bugs/?49100.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Since all lines can be partially scrolled off the screen now
(except for edittop, which is forthcoming), the maxlines global
variable and its computation mechanism are no longer needed.
Use go_back_chunks() to adjust edittop, instead of special casing
the computation of goal when softwrapping. Now softwrap mode and
non-softwrap mode will behave the same way when edittop can be
partially scrolled off the screen, which is forthcoming.
(Note that the top line of the screen can't be partially scrolled
yet, so we have to work around that for now.)
Use go_back_chunks() and go_forward_chunks() to adjust edittop and to
move up or down to the scrolled region before updating the rows there.
Now softwrap mode and non-softwrap mode will behave the same way when
we can scroll the top line of the screen partially off the screen,
which is forthcoming.
(Note that the top line of the screen can't be partially scrolled yet,
so we have to work around that for now.)
Not drawing a line on a row if we're on the top row and scrolled down,
or if we're on the bottom row and scrolled up, will only work properly
if the line on that row takes up only that row. The latter might not
be the case in softwrap mode: if the line occupies multiple chunks and
begins on that row -- in that case none of the chunks would be drawn.
Add the new functions current_is_above_screen() (which doesn't account
for softwrapped chunks yet, but will when we can scroll edittop partially
off the screen, which is forthcoming), current_is_below_screen() (which
determines whether current[current_x] is past the softwrapped chunk at
the bottom of the screen), and current_is_offscreen() (the union of the
previous two functions).
edit_redraw() and edit_refresh() now use current_is_offscreen() to check
whether they should adjust the viewport, and adjust_viewport() now uses
current_is_above_screen() to determine whether current is on or below
the screen in FLOWING mode.
Add the new function less_than_a_screenful() to accomplish this.
It uses go_back_chunks() to count the number of softwrapped chunks
between the end point and the starting point of the paste.
Now softwrap mode and non-softwrap mode behave the same way when
uncutting fewer than editwinrows rows of text. Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.
These functions, go_back_chunks() and go_forward_chunks(), take a number
of softwrapped chunks (screen rows) to move, a pointer to a buffer, and
a location (specifically, a starting column of a softwrapped chunk). If
they move successfully, they will update the buffer pointer and location
to point to the beginning of the softwrapped chunk they moved to.
Since non-softwrap mode is effectively just a subset of softwrap mode
in which every line takes up one chunk, these functions also work in
non-softwrap mode. In this case, their starting column will always be
zero, as it would be in softwrap mode on a line that takes up one chunk.
Nothing uses these functions yet, but that is forthcoming.
Instead of redetermining the entire span of the converted string,
simply move one character left, and then bite it off to make place
for the trailing $.
If the last two columns of a row would be taken up by a double-width
character (and the line is longer than that), don't print it, because
it wouldn't leave any room for the $ character.
This fixes https://savannah.gnu.org/bugs/?50491.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Running strlenpt() on a string that takes up more than 80 columns
(the width of an average terminal) takes /more/ time than simply
converting an extra character (the one that will be overwritten
by the "$" at the edge of the terminal). So... just convert one
more character than necessary when the line is overlong. In the
most common case, however, the line will fit fully onscreen, and
we save a whole call of strlenpt().
Since we only need span columns of the string, stop scanning the string
as soon as we have that many columns, instead of scanning the string all
the way to the end. This speeds up the conversion of very long lines.
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.
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.
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.)
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.
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.
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.
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.
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>
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.
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.
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.
It does not update anything -- it just picks a new point from
where to start displaying the buffer. All actual updating of
the screen is done by edit_refresh() and edit_redraw() and such.
It can be activated with --linenumbers on the command line or with
'set linenumbers' in a nanorc file, and it can be toggled with M-#.
Signed-off-by: Faissal Bensefia <faissaloo@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Returning a zero would mean returning a ^Space -- the keycode that
by default is bound to the Next-Word function. So, unbinding the
keys to which the modified Arrow keys are hard bound would cause
the latter ones to mysteriously jump to the next word.
This partially fixes https://savannah.gnu.org/bugs/?49058.
Add the keycodes and routines to allow the user to forego setting the
mark explicitly (with M-A / ^6) and instead quickly select a few words
or lines by holding down Shift together with the movement keys.
(Some combinations with Shift are swallowed by some terminal emulators.
To work around some of those, the combinations Shift+Alt+Left/Right work
as Shift+Home/End and Shift+Alt+Up/Down work as Shift+PageUp/PageDown.)
This also prevents the message from spilling into the help lines
when the terminal is less than four columns wide. (Not that one
can read anything then, but it looks better.)
For horizontal scrolling, it is not the /desired/ column position that
is relevant for determining whether a line needs to be redrawn after a
cursor movement, but the /actual/ column positions before and after.
This fixes https://savannah.gnu.org/bugs/?48627,
and fixes https://savannah.gnu.org/bugs/?48629.
Leave the rest of any escape sequence to be processed normally, which
should be possible because those characters are all in ASCII range.
This fixes https://savannah.gnu.org/bugs/?48318.
And hard-bind the keys Ctrl+Up and Ctrl+Down to these functions.
Unlike the paragraph-jumping code, these new functions disregard
any indentation, treating only blank lines as separators. They
also do an automatic smart home when that option is set.
This fulfills https://savannah.gnu.org/bugs/?48291.
Also, compose the coloring attributes during initialization
instead of every time when painting something.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Instead of referring to a window that might have been deleted by a
resize, just turn the keypad back on for the two windows from which
input might have been requested.
Also: don't insert KEY_WINCH as the verbatim keystroke.
This fixes https://savannah.gnu.org/bugs/?48532.
When the user changes her mind after having pressed Esc, she cannot
unpress Esc, so do that for her by ignoring the escape code when
the subsequent keycode is outside of the normal printable range.
This restores the behavior from before nano-2.3.5 -- except that
Ctrl+Alt+key continues to report an unbound key.
This fixes https://savannah.gnu.org/bugs/?48459.
This prevents many keycode sequences from being misconstrued when a
command key plus other keystrokes accumulate in the input buffer.
This fixes https://savannah.gnu.org/bugs/?48395.
Add them so that <Esc> followed by <Home> will simply do "Home" instead of
reporting an unbound key. The same for <End>, <PageUp> and <PageDown>.
This restores the behavior from before nano-2.3.5.
Just allocate ample space up front and thus discard the delaying 'if' for
each and every character. In most cases this will allocate far too much,
but that hardly matters: it is freed again as soon as the line is printed.
Keystrokes are single integers (aided by the flags meta_key and
func_key) but in the input stream they can be encoded as escape
sequences (a series of bytes). Characters are values in byte
range, but in UTF-8 one character can consist of multiple bytes.
Also rename two variables, because the secondary input buffer
that they refer to contains only characters (mostly just one),
never any shortcuts; and there are too many "kbinput" already.
Error messages about lock files should not get overwritten by purely
informational messages, only by alerting ones.
This fixes https://savannah.gnu.org/bugs/?47963.
If during startup there are multiple error messages, currently only the
last one remains and can be read. To improve on that, introduce a short
pause between error messages -- even if it's not enough to read them all,
at least the user will be aware that there are multiple ones.
This also causes a few error messages to beep that currently don't beep,
such as when a file is unwritable.
CONST_UPDATE is only relevant when in the main menu, not when in the
browser. So, check for that condition, instead of saving, changing,
and then restoring the setting.
Cancelling a search should restore waiting mode for the keyboard,
just like at the other exit points of the search routine.
And when the input routine has read in multiple keystrokes, it
should not blindly switch back to waiting mode, but only when
that mode was on before.
This fixes the second half of https://savannah.gnu.org/bugs/?47438.
When the terminal is very narrow, there is little point in showing only
part of the version string -- and chewing off one or two digits from the
version number might even give someone a wrong idea. The user is better
served with always showing the full filename, as long as it fits in the
available screen width.
This fixes https://savannah.gnu.org/bugs/?47703.
For some reason the keyboard code seems to assume that all integers
waiting in the keybuffer form a single sequence. But this isn't the
case: when there is an escape (0x1b) among them, then that is where
a new sequence starts. So, prevent the input code from considering
an escape after a non-escape as part of the current sequence.
This fixes https://savannah.gnu.org/bugs/?47839.
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.
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.
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.
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>
invalid escape sequence, and when entering a verbatim keystroke.
But leaving the cursor off during Unicode input, for extra feedback.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5771 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
anyway, and it will be placed back when it's needed: in the main loop.
This prevents a segfault laid bare by r5763: when trying, at startup,
to open a directory, there really is no open buffer yet.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5766 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
variable for a little optimization.
Openfile can never be NULL -- it should have been called openbuffer, and
before we start fiddling with the cursor, we will always have an open buffer.
Edittop might be NULL, but that's okay.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5763 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
David Lawrence Ramsey