Also, only unindent when all selected lines can be unindented,
which means that the relative indentation will be preserved.
For this purpose, it ignores empty lines and lines consisting
of only whitespace.
When unindenting is not possible, a message is shown.
This fixes https://savannah.gnu.org/bugs/?47684.
Instead of inserting the extra whitespace after the current indentation
of a line, add it to the start of the line. This causes a fixed amount
of visual whitespace to be added regardless of whether --tabstospaces
is used or not.
This fixes http://savannah.gnu.org/bugs/?51438,
and its ancestor https://savannah.gnu.org/bugs/?51408.
So that these functions have bindings by default, and easy bindings.
Add them to the help viewer too, so that searching backward becomes
possible there.
Tabs are of variable length depending on position, so allow them
to be displayed partially on one chunk and partially on another.
This fixes http://savannah.gnu.org/bugs/?51621.
Adding text plus whitespace while the cursor is at or near the topleft
corner of the edit window can cause a change in the preceding chunk,
throwing firstcolumn out of alignment. Catch this special case.
This fixes http://savannah.gnu.org/bugs/?51743.
It would be horrible if the user expects to find numbered backups
of all the files that were changed but they are NOT there because
the config file contains a typo or the relevant directory was moved
or renamed or something. So... if the specified backup directory
is not usable, nano should complain and simply not start up.
Discarding (in commit 6f9bb53b) the cap on the number of chunks to
move backwards had as an unforeseen side effect that the screen can
fail to scroll when the cursor is somehow pushed offscreen.
Fix this by setting the target row (for smooth scrolling) always to
the bottom row of the edit window when nano notices that the cursor
has gone offscreen.
This fixes https://savannah.gnu.org/bugs/?51676.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>
The succeeding character was needed to avoid miscolorings due to nano
getting confused about starts and ends. But since commit 7ef5c532,
nano should be getting the starts and ends always right, so... undo
"temporary" commit 7b2ea405 from two years ago.
This addresses https://savannah.gnu.org/bugs/?51526.
Reported-by: <exodus6395@googlemail.com>
The new option 'set selectedcolor' applies to marked text, to the
currently selected file in the file browser, and to the highlighted
match during interactive search-and-replace.
Include the shortcut for 'Uncut' into most menus, and add an uncut
function for the status bar, so that it becomes possible to paste
the first line of the cutbuffer at any text-input prompt.
This fulfills https://savannah.gnu.org/bugs/?48501.
Requested-by: Benno Schulenberg <bensberg@telfort.nl>
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Assume that a linter line that contains an actual error message or
warning includes a colon followed by a space -- something that that
opening message from a modern gcc lacks.
Human column numbers are one-based, whereas x positions are zero-based.
Converting from the one to the other involves subtracting one. But when
the linter message does not provide a column number, the latter defaults
to zero. Catch that case and change the number to one.
This fixes https://savannah.gnu.org/bugs/?51550.
Commit 28beb3f added the 'forreal' parameter to prevent spotlight() from
placing the cursor wrongly due to an invalid placewewant. However, since
the variable-width softwrap overhaul (specifically, since commit 8490f4a),
place_the_cursor() no longer checks placewewant, so the parameter is no
longer needed.
Furthermore, dropping 'forreal' and thus always setting current_y won't
affect the operation of spotlight(), since the only functions that use
spotlight() (do_replace_loop() and do_int_spell_fix()) both call
edit_refresh() beforehand, which means that current_y will already
have been set to the value it will be set to again.
The function place_the_cursor() assumes that the viewport is up to date,
i.e., that current is in range of edittop. When uncutting or inserting,
however, place_the_cursor() gets called on the out-of-date viewport
first, and then a screen refresh is scheduled (which would put the
viewport up to date). This is backwards: the refresh should come before
the cursor placement, and the only reason it works anyway is because the
cap on the number of chunks to move backward papers over the problem by
keeping current_y in screen range regardless.
Fix this properly by simply setting current_y to the bottom row of the
screen instead of calling place_the_cursor(). This value of current_y
is only ever used when in smooth scrolling mode and the insertion (or
paste) pushed the cursor offscreen. In other situations, this value is
overridden when place_the_cursor() gets called after a screen refresh.
After that fix, the cap on the number of chunks to move backward is no
longer needed.
Benno Schulenberg