The short option '-?' was removed nine years ago in commit 43019189,
then restored six years later in 5bd92d4c, and then removed again two
months later in 743100fe due to getopt() returning '?' for options
that aren't recognized, preventing the use of '-?' as a valid option.
However, getopt() provides a way to check for unrecognized options
via the 'optopt' variable, which gets set only for invalid options.
Signed-off-by: Mateusz Kazimierczuk <mataha+savannah@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When the directory that the user is browsing in is deleted by another
process at the moment that nano is building the list of file names,
this can result in an empty list, which some items in the main loop
in browse() cannot handle. Prevent this mishandling by not entering
the loop when the list is empty.
This fixes https://savannah.gnu.org/bugs/?64465.
Reported-by: Jerry Meng <jerrytstng@gmail.com>
Speller, linter, formatter, and execute-a-command cannot be used in
restricted mode, but the relevant keys should report that the function
is *disabled*, not that the key is unbound.
This fixes https://savannah.gnu.org/bugs/?64226.
Problem existed since version 3.2, since nano reads the nanorc files
also in restricted mode.
With some imagination, the lack of access could be inferred from the
other descriptions, but it's much better to be clear and explicit.
Also, separate two items that are unrelated and reshuffle them into
a neater order.
Triggered by https://savannah.gnu.org/bugs/?64181.
This seems to be the convention. For an example, see `man tar`.
This addresses https://savannah.gnu.org/bugs/?64125.
Reported-by: Eric S. Raymond <esr@thyrsus.com>
This suppression prevents the filename flashing by at the bottom
of the screen when switching between buffers.
This addresses https://savannah.gnu.org/bugs/?64019
Reported-by: Alan Cristhian Ruiz <alancristhian@protonmail.com>
Problem existed since version 6.0, since --zero was introduced.
I already added this for myself since I've been using this patch for a while
so I figured I'd include it. This simply makes it possible to colorize the
folded segments as the user desires. An option 'foldedcolor' is enabled for
the rcfile.
Signed-off-by: rexy712 <rexy712@protonmail.com>
In order to test the functionality, one actually has to be able to build it!
This patch adds an option to the configure script, builds 'folding.c', and
adds a shortcut to make folding possible. The shortcut here is set to 'M-['.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Not everything is as simple as just UNFOLD_SEGMENT. These are the cases where
specific modifications were needed. Most of the actual heavy lifting was done
when modifying the functions 'update_line' and 'do_prev_word'.
Most of the changes here actually came down to 'get_row_from_edittop' or
changing from 'update_line' to 'update_line_at'.
Signed-off-by: rexy712 <rexy712@protonmail.com>
When adding folding lines, the lines drawn on screen are no longer
guaranteed to increment one by one. There could be a large skip when
handling folded segments. So instances where the codebase assumed
'openfile->current->lineno - edittop->lineno' would yield the position
on screen of the current line needed to be modified. Similar problems
existed in many places so a function 'get_row_from_edittop' handles
finding the current position of a line in relation to 'edittop'.
Signed-off-by: rexy712 <rexy712@protonmail.com>
The bracket search functions 'find_a_bracket' is very useful for searching for
region to fold when no selection is made. To make this possible, the function
needed to be modularized so it could be reused in a way not originally
intended.
The functions 'do_prev_word' and 'do_next_word' were interesting in that
sometimes it is desirable to get the corresponding word within a folded
segment and sometimes it was better to skip folded segments. So a boolean
parameter seemed like a good way to not duplicate functionality while
making the function work for both cases.
The 'update_line' function only worked in relation to edittop from the
given line's lineno. This obviously won't get the correct position if
there are folded lines. So I added a new function 'update_line_at' to
allow specifying where in the window to update when calling the function.
The original 'update_line' still exists to not modify existing code
utilizing it.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Nano's existing functionality needs to mesh with the ability to
fold lines. The most common of these issues is needing to unfold
when a line is updated or the user accesses a line inside of a folded
segment. This patch handles all the places this can be done simply
with a 1 or 2 line modification.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Adds in some preprocessor directives for easily adding in unfolding
support to existing functions that require it. Also adds in some
helper functions in 'folding.c' for common tasks which will need
performed. And of course add the 'folded' boolean to the linestruct
type so we know which lines are currently folded.
Signed-off-by: rexy712 <rexy712@protonmail.com>
Various tools will output filenames with line numbers in the format
<filename>:<line>:<column>. Support this format in addition to the
+<line>,<column> format when opening files.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The isxxxxx() functions expect their parameter to be either EOF or
a value in the unsigned char range. Passing a negative char value
could (in theory) result in unexpected behavior.
In view mode it should be impossible to modify any buffer, but...
when (through some bug) the user did succeed in modifying a buffer,
this should not lead to writing out this modified buffer to disk.
Had this safety stop been present earlier, it would have prevented
the second part of https://savannah.gnu.org/bugs/?63616.
A string bind can only contain bytes (chars), not keycodes (integers,
in nano upto 0x4FF). So, apart from an error code or a placeholder
command code, get_code_from_plantation() can only return a byte.
The function get_code_from_plantation() should return ERR only when
the string bind is fully exhausted. In the normal case, where some
bytes are still available, it should return the first of these bytes,
so that the {verbatim} function will work too.
This fixes https://savannah.gnu.org/bugs/?63702.
Bug existed since version 7.0, commit 958ec294,
since command cartouches were introduced.
This separation avoids the impression that we're thanking the mentioned
people for their use of nano (something they probably don't do).
(Also, remove two other blank lines -- effectively moving these two
lines further up, keeping the total amount of whitespace the same.)
