Option -J (--guidestripe) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to aid the user in regulating the width of the text when the terminal
is wider than this desired width.
This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero González <arturo@debian.org>
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ <bryan.christ@gmail.com>
When the right half of a two-column character gets overwritten by the
">" continuation character, then represent its left half as "[" also
when spotlighting a replacement candidate. Achieve this by calling
display_string() in the overshooting case with 'isprompt' set to TRUE,
which also makes this function reserve space for the ">" continuation
character so spotlight() doesn't need to do this any more.
This fixes https://savannah.gnu.org/bugs/?55679.
Improved-by: Benno Schulenberg <bensberg@telfort.nl>
The change in commit edc0d628 was flawed. The old logic covered
every case but one: having reached the end of 'buf' but 'column'
still having overshot the screen width. Now cover this latter
case too.
This fixes https://savannah.gnu.org/bugs/?55638 properly,
allowing the next commit to fix another buglet.
Condensed-by: Benno Schulenberg <bensberg@telfort.nl>
In this way, for single-width characters, one can see what character is
ahead of the cursor before actually moving the cursor to that position,
and, for double-width characters, the cursor never sits on a placeholder
but always shows the character that is actually there.
This addresses https://savannah.gnu.org/bugs/?55716.
In the tiny version the feature toggles are absent, so most of the
Meta-key combinations do nothing, and when --with-slang was used, the
<Ctrl+Left/Right> keystrokes do not work (as they produce truncated
escape sequences under Slang), and the <Ctrl+Space> and <Alt+Space>
keystrokes are awkward to type and make no sense. So... use some
of the free Meta combinations to jump a word to the left or right,
since these functions *are* present in the tiny version.
The reload_positions_if_needed() routine can free the existing
'position_history' and allocate a new one. Using the old one,
from before the reload, could lead to a crash.
This fixes https://savannah.gnu.org/bugs/?55792.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Bug existed since the reloading of the position-history file was
introduced, a year and a half ago, in commit bfc53f30.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
That is: keep nibbling off characters until a character is eaten that
takes up at least one column.
This fixes https://savannah.gnu.org/bugs/?55759.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
Bug existed since version 2.8.0, commit 5283acdc.
On small terminals (80 columns or so), ^S and ^Q would be in
the last position of the help lines. But some terminals might
intercept ^S and stop all output (until ^Q is pressed), which
could be unexpected and frustrating. So, rearrange things for
the tiny version so that ^S appears only on very wide terminals.
Also, having two keystrokes for saving the current buffer
(^O and ^S) in the two help lines is wasteful, more so as
in the tiny version there are no ^G help texts.
So, show the more useful M-Q and M-W instead.
This addresses https://bugs.debian.org/915017.
Reported-by: Steve McIntyre <steve@einval.com>
If these two command-line options would override an rcfile setting of
their counterpart new option, the user might come to expect being able
to do this also in the future. But these old options will be obsoleted
at some moment, so... better start ignoring them right now.
The start-of-paragraph and end-of-paragraph seeking functions are only
vaguely related to searching, and have nothing to do with replacing --
the functions make more sense in the Goto-Line menu.
Also, the Goto-Line menu is much less crowded, so the functions are
more likely to be noticed there. Furthermore, this makes harmless a
typo that I sometimes make: typing ^W again when I've already done so.
Jumping to the first or last line of the buffer doesn't have anything
to do with searching, so these functions shouldn't be present in the
search menus. They make perfect sense in the Goto-Line menu, though.
