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 tiny version can do regex searches nowadays, so the user might use
the \< and \> anchors in their regexes.
This fixes https://savannah.gnu.org/bugs/?50008.
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.
The setting of current_y in copy_from_filestruct() also appears to be
a holdover from the days of a more-common STATIONARY scrolling mode.
do_cut_text() uses the above function when copying text (uncutting
text again right after cutting it). Since the text is effectively
the same afterward, current_y doesn't need to change.
do_uncut_text(), however, does need current_y up to date in one case:
when uncutting a full screen or less' worth of lines, focusing will be
FALSE, and it uses edit_refresh(), so it will use STATIONARY scrolling
mode then. Take a cue from do_insertfile() and call reset_cursor() to
get an updated current_y.
(Note that the check for a full screen or less' worth of lines uses
incorrect values when in softwrap mode, but that's a separate problem.)
undo_cut(), do_redo(), and backup_lines() do not need set current_y
because they all result in edit_refresh() with focusing = TRUE, so
they do a CENTERING scroll which does not need current_y.
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.
A tag begins not merely with a "<" but it must be followed by an
ASCII alphabetic character or one of "/", "!" and "?".
Further, color all the valid attribute names in red.
That is: only extend the current Del or Backspace undo item when the
cursor is still (or again) at the same spot.
This fixes https://savannah.gnu.org/bugs/?50006.
If the system on which nano is configured does not have the 'makeinfo'
program installed, the prebuilt and packaged nano.info and nano.html
should nevertheless be installed.
Also, the TEXINFOS primary has built-in rules for generating HTML files
from the texinfo sources, so an explicit rule is not needed.
This indirectly addresses https://savannah.gnu.org/bugs/?49969.
Instead of setting openfile->current_y (and wrongly so), just call
reset_cursor() to recompute current_y and place the cursor on that
line (if it is not offscreen).
The search routine begins searching right after the cursor and behaves
as if the line starts there, which means that a beginning-of-word anchor
(\< or \b) will match there also when in fact the cursor is sitting in
the middle of a word. To prevent finding a false match, verify that
for a regex that starts with a BOW anchor the found match is actually
the start of a word.
This fixes https://savannah.gnu.org/bugs/?45630.
Since do_mouse() uses edit_redraw(), openfile->current_y will be
immediately recalculated, so there's no point in changing it now.
Use a temporary variable instead.
The value of sameline doesn't change, so it can be initialized to that.
Since i holds openfile->current_y, it should be ssize_t, not size_t.
And it's better to do the most significant part of a calculation first.
Many of the adjustments of the value of openfile->current_y appear to be
a holdover from the days when certain functions had to account for what
is now called STATIONARY scrolling mode, which depends on the value of
current_y. Remove these adjustement where they are superfluous.
do_para_begin(), do_para_end(), and do_bracket_match() update the screen
through edit_redraw(), which uses either CENTERING or FLOWING scrolling
mode, so their setting of current_y is redundant and useless, as it will
be ignored and then overridden by the next call to reset_cursor().
findnextstr() is called by go_looking() [which calls edit_redraw(), see
above], and by do_replace_loop() and do_int_spell_fix(), which both call
edit_refresh(), which in this case only uses CENTERING scrolling mode
since focusing is TRUE.
(Additionally, the adjustments of current_y in findnextstr() and
do_bracket_match() use incorrect values when in softwrap mode.)
find_paragraph() doesn't need to save or restore current_y, because it
doesn't do any screen updates. do_justify() calls edit_refresh() with
focusing set to TRUE, so it uses the CENTERING scrolling mode.
do_alt_speller() and do_formatter() do not need to save and restore
current_y, because they don't modify it in any way.
This addresses https://savannah.gnu.org/patch/?9197.
This makes nano's cursor behavior consistent across 1) typing text by
hand; 2) pasting in text with ^U; 3) inserting text from a file; and
4) redoing with M-E that same typing or pasting or inserting.
This fixes https://savannah.gnu.org/bugs/?49968.
There are just a handful of source files for the documentation --
it is wasteful and cumbersome to have these in separate directories.
Also: remove the French man pages -- they are too far out of date.
(And anyway, we should acquire a general framework for translating
the documentation.)
The warning is wrong when the user has just saved a buffer under a
new name. And when --quickblank is used, the warning most likely
gets cleared off before it is seen, and the user would just hear
the beep and be left wondering what happened.
This avoids https://savannah.gnu.org/bugs/?49875.
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.
Also at the yes-no prompt, a 0x0A byte should be displayed as a ^J
instead of splitting the prompt bar in two and spreading it over
two lines.
This fixes https://savannah.gnu.org/bugs/?49934.
After a call to the Formatter or the Alternate spell checker, the data
on the undo stack could refer to line positions that don't exist any
more -- the chance is small, but it is there. So... throw the whole
undo stack away, to prevent undoing things wrongly or even crashing.
(Changes made with the internal spell checker can be undone and redone
without a problem -- nano keeps full track of those. But the changes
made with a formatter or an external spell checker happen in another
process, so nano has no record of them.)
This fixes https://savannah.gnu.org/bugs/?49920.
When using an external spell checker or formatter, the line with
the cursor might become shorter, which might result in the stored
cursor position being beyond the end-of-line. So, when restoring
the x position, make sure to limit it to the length of the line.
This fixes https://savannah.gnu.org/bugs/?49923.
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.
Decode 0x0A bytes to 0x00 when saving the search history, and encode
them again when reading the file back in, to prevent nano from hanging
or aborting when encountering 0x00 on a line by itself.
After updating the color palette, the corresponding new window content
should be drawn immediately, before some other part of the code calls
doupdate(), to prevent the old content being shown in the new colors.
This fixes https://savannah.gnu.org/bugs/?49912.
Reported-by: Mike Frysinger <vapier@gentoo.org>
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>
A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.
This fixes https://savannah.gnu.org/bugs/?49879.
So they will not break a line in the positionlog file in two.
(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)
This fixes https://savannah.gnu.org/bugs/?49877.
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.
Most full paths are needed only temporarily and will be freed within
milliseconds. Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session. Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.
That is: elide a second test from the most travelled path: a valid
character. This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.
The fsfromline() function is mostly used by the undo functions, which
are not present in the tiny version. It is also used by the comment/
uncomment feature, but this feature cannot be enabled when --enable-tiny
is in effect.
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.
An added magic linefeed should be removed again /before/ restoring
the x position, as the latter needs to be calculated from the real
last line of the region.
This fixes https://savannah.gnu.org/bugs/?49817.
Reported-by: Mike Frysinger <vapier@gentoo.org>
When wanting to debug something, it is far more useful
to temporarily insert lines like:
statusline(ALERT, "name = %i", variable);
It provides instant feedback, and it slows things down,
so you can kind of see what happens.
The functions read() and fwrite() take size_t, not ssize_t.
And line numbers in the file should be displayed as a long type instead
of an int, since the effective type of ssize_t is not int, but long.
(The variable 'pletion_line' is not conditionalized with this option, as
it would become messy. The compiler will probably be able to elide it.)
When using --enable-tiny, it is not possible to use --enable-wordcomp,
because the word completion function uses the undo system.
Executing the 'complete_a_word' function will search from the start
of the current buffer for entire words that begin with the fragment
that is before the cursor, and will complete this fragment to the
first word that is found. Each consecutive call of 'complete_a_word'
will search for the next matching word and will complete the fragment
to that. By default the function is bound to the ^] keystroke.
Signed-off-by: Sumedh Pendurkar <sumedh.pendurkar@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
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.
If it would, the returned file descriptor would make nano crash,
because the corresponding stream has not been opened. And when
returning zero instead (as the code did originally), nano would
open an empty buffer, although it claims to be reading the file.
In short: I think this is a leftover of an attempted fix of
https://savannah.gnu.org/bugs/?25297, from commit 2823c99.
We should avoid defining color schemes that are unreadable on common
white-on-black or black-on-white terminals. Change the black in the
autoconf error strings to brightred for that reason.
When probing symbols provided by ncurses, use the sublibs that pkg-config
reported in case they're needed (like when libtinfo is a sep library).
URL: https://savannah.gnu.org/bugs/?49614
- make version highlight less blindly greedy and conform to real versions
- move version matching before USE matching to avoid hitting USE flags
that look like versions
- change USE regex to match the Gentoo PMS
- extend arch match to include more keywords
- make category matching more restrictive to avoid false positives
- drop operators =< and => that Gentoo doesn't support
URL: https://savannah.gnu.org/bugs/?49569
Reported-by: Konstantin Shakhnov <kastian@mail.ru>
Otherwise the user can override a 'set nowrap' in /etc/nanorc only
via the command line.
This fixes https://savannah.gnu.org/bugs/?49593 reported by Shirish.
When giving a line number on the command line, do_gotolinecolumn() needs
to know the width of the screen to be able to (roughly) place the target
line in the center of the screen.
This fixes https://savannah.gnu.org/bugs/?49462.
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.)
Even when the edit window consists of just one or two lines, the PageUp
and PageDown functions (^Y and ^V) should continue to move the window.
This fixes https://savannah.gnu.org/bugs/?48805.
When using the default speller or the formatter, the placewewant is
remembered. So it should be remembered too when the user specifies
a different speller.
(This behavior was inadvertently lost last year, in commit 82d737e.)
It is quicker to do a handful of superfluous compares at the end of
each line than it is to compute and keep track of and compare the
remaining line length the whole time.
The typical line is some sixty characters long, the typical search
string ten characters -- with a shorter search string the speedup is
even higher: some fifteen percent. Only when the string is longer
than half the average line length does searching become slower with
this new method.
All this for a UTF-8 locale. For a C locale it makes no difference.
Now that mbstrncasecmp() does the right thing, there is no need any
more to verify that only a valid multibyte sequence was matched.
(See https://savannah.gnu.org/bugs/?45579 for a test case.)
Also, this will make it possible to search for invalid sequences.
(Currently it isn't possible to enter a search string with invalid
characters, but... a user might edit the search history file. And
if pasting at the prompt is implemented, it will be trivial to enter
invalid sequences if you have a file that contains them.)
Persisting might lead to count 'n' reaching zero, which would mean that
the needle has matched, which is wrong when one of the strings contains
an invalid or incomplete multibyte sequence.
That is: don't run towlower() on the two differing bytes when having
reached the end of one of the strings.
This fixes https://savannah.gnu.org/bugs/?48700.
In the bargain, don't do the conversion to lowercase twice.
Furthermore, persist when encountering invalid byte sequences --
until finding bytes that differ.
The needle is never part of the hay -- it is always a separate string.
(And even if needle and haystack were identical, the routine works fine,
the case does not need special treatment.)
When doing an <Up> on the top line, or a <Down> on the bottom line of
the edit window, the affected lines have already been redrawn by the
scrolling code, so there is no need to do that again.
(However, that does not prevent the second line (or the last-but-one
line) from being redrawn unnecessarily when using the M-- (or M-+)
command elsewhere on the screen and /that/ line is horizontally
scrolled. But we'll let that pass for now.)
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.
Also, when a key string does not denote a Ctrl nor Meta nor Function key,
there is no point in assigning a keycode, because plain characters cannot
be used as a function shortcut.
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.
This allows the user to specify which other characters, besides the
default alphanumeric ones, should be considered as part of a word, so
that word operations like Ctrl+Left and Ctrl+Right will pass them by.
Using this option overrides the option --wordbounds.
This fulfills https://savannah.gnu.org/bugs/?47283.
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.
It is easy to type beside the comma key and hit instead "m" or ".", so
accept also these as a separator between line and column number. And
when being generous anyway, also accept space, slash and semicolon.
This fulfills https://savannah.gnu.org/bugs/?48305.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Precalculation of the multiline color data can be cut short when the
user is impatient and starts typing. But this would drop the first
byte of whatever was typed -- not nice when it was just plain text,
but surprising and worse when the first keystroke was a command.
This fixes https://savannah.gnu.org/bugs/?48388.
When for a multiline syntax-coloring rule the starting regex matches at
the exact same spot as the ending regex, do a second round of resets, so
that reevaluation starts further back and gets a few more things right.
This mildly fixes https://savannah.gnu.org/bugs/?47420.
When we get a ^J as verbatim input, it is not possible to include it
into the file buffer or the prompt answer, because this would mean
adding an encoded null to the buffer or answer, and that is not what
the user intended. One option would have been to simply ignore a ^J
in verbatim input. But the choice has been made to act the same way
as when the ^J (0x0A) is found in the file data: start a new line.
That is the same response as to the Enter key, yes -- but the code
for the Enter key is ^M (0x0D), not ^J. So, to be more precise,
rename the relevant variable from 'got_enter' to 'got_newline'.
When the user tab-completed a name at the Go To Directory prompt, this
name will end in a slash. Remove this slash, so the name can be found
in the file list (where directory names don't include the final slash).
This fixes http://savannah.gnu.org/bugs/?48353.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Invalid multibyte sequences get depicted with the Replacement Character,
and unassigned codepoints are shown as if they were a space. Both have
a width of one.
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.
Also, other messages that are about --operatingdir don't use the term
"confined" either.
Suggested-by: Mario Blättermann <mario.blaettermann@gmail.com>
Don't make it the responsibility of the executed functions to restore
the list of shortcuts of the edit window. Just detect whether another
menu was displayed, and if so, redisplay the main menu.
The way to update nano.pot is to run 'make nano.pot-update' in the po
subdir. Updating a specific PO file is then done with 'make xx.po'.
(The script mistakenly included all leading comments, not just the
ones marked with "TRANSLATORS:".)
It sounded like an instigation to upgrade, or like a list of
instructions on how to upgrade. But it is merely a list of
noteworthy changes -- what other packages put in the NEWS file.
To add a character, one does not need to allocate twice its size.
And the amount to be moved does not depend on the size of the new
character; it just needs to include the terminating zero.
(This fixes in do_output() the same logical mistakes that were fixed
in do_statusbar_output() last February, in acf19bd and 7c0e433.)
Specifying an operating directory should either lead to a successfull
confinement, or nano should fail to start.
(Also: save the terminal settings as soon as possible, so that an early
die() will not restore uninitialized values.)
This fixes the first part of https://savannah.gnu.org/bugs/?47798 properly.
This fixes https://savannah.gnu.org/bugs/?48103.
(The fix is wasteful -- it should only discard the multidata if actually
the name *did* change, *and* if the applicable syntax changed.)
By moving the test for the only situation where do_comment() does nothing
(when only the magic line is selected) further up front, the add_undo()
can be called before the commenting/uncommenting starts and two variables
and an extra function are made unnecessary.
That is: don't mix the number of lines read with a warning about the
file being unwritable -- the former is just convenience information,
the latter is a must-see.
This fixes https://savannah.gnu.org/bugs/?48047.
When running in a non-UTF locale, and when strncasecmp() suffers from
the same defect as strncmp(), make sure not to pass a length with the
high bit set.
This reverts commit df8c3de from six years ago, which prevented a crash
on the Armel/Maemo platforms but causes nano to lose history items.
The strncmp() function on those platforms treats size_t numbers with
the high bit set as if they were zero. To avoid that, use a number
that cannot be seen as negative, as suggested by <alpha@qzx.com>.
This fixes https://savannah.gnu.org/bugs/?48048.
Tested-by: Tito Ragusa <farmatito@tiscali.it>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Store the file sizes from before and after the commenting/uncommenting
in the undo struct, so they can be restored when undoing or redoing.
This fixes https://savannah.gnu.org/bugs/?48062.
Signed-off-by: Mike Scalora <mike@scalora.org>
When opening a file that was edited before, and the remembered position
is near the end of the file, then don't center the target line but show
the last line of the file on the bottom line of the screen, thus showing
as much of the file content as possible.
This addresses https://savannah.gnu.org/bugs/?46243.
Instead of parsing every multibyte character twice, first with
parse_mbchar() and then with mbtowc(), just let mbtowc() do all
the work. This makes searching for a fixed string twice as fast.
This also gets rid of four variables and lots of memory allocations.
(And, more importantly: it stops nano messing up the internal state
of the multibyte-to-wide character conversion, and thus would make
the calls to mbtowc_reset() superfluous.)
This allows for commenting or uncommenting a line or a bunch of lines
with a single keystroke (default binding: M-3). The characters used
for commenting/uncommenting are specified by the active syntax file.
Reviewed-by: Benno Schulenberg <bensberg@justemail.net>
Signed-off-by: Mike Scalora <mike@scalora.org>
Move the initialization of the operating directory to after the
initialization of the screen, so that the above error can be shown.
This fixes the first part of https://savannah.gnu.org/bugs/?47798.
Between the first stat (that sets 'realexists') and the second stat
(directly after), the file might have disappeared, which would mean
that current_stat would be NULL. Prevent dereferencing this further
down.
Only when the user decides not to override an existing lockfile should
loading the corresponding file be skipped. Any failure to write the
lockfile should be ignored -- the file itself should be loaded anyway.
This fixes https://savannah.gnu.org/bugs/?47945.
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.
The variable 'namecopy' has been passed to dirname(), so it is likely
to have been changed when it contains a slash. So, use a new variable
instead. Also, free the result of display_string().
This fixes https://savannah.gnu.org/bugs/?47956.
Having just opened a fresh buffer, 'openfile->next' will never be NULL,
because the list is circular.
Second, when compiled with --disable-nultibuffer, and deciding not to
override an existing lock, the 'return FALSE' should *not* be skipped,
because otherwise the named file will be opened after all.
This fixes an unreported bug.
Either the selected file was changed, or a file or directory was chosen
(and the Enter key virtually pressed), or a shortcut was executed. So,
just go and read the next key.
This fixes https://savannah.gnu.org/bugs/?47944.
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.
When doing a PageUp or PageDown in the browser, don't move the highlight
to the first line in the same column, but keep it in the same relative
position of the screen. If we're already on the first or last page,
move the highlight to the first or last line, but keep it in the same
column. If we're already on the first or last line, only then move it
to the first or last entry.
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.
There is no need to iterate through all the file names, as we already
know the length of the longest. From this it's easy to calculate how
many names fit on a line.
Also rename some things to be more fitting. And make sure that something
will be selected even when many files, including the selected one, have
disappeared.
When refreshing the screen (and thus the file list), use the prev_dir
mechanism to reselect the file that was selected before the refresh,
to prevent the selection from changing when files were added or deleted.
Also, when the selected name has disappeared, move the highlight one step
back, so that it is obvious that the selection has changed. (Decrementing
'selected' will never make it negative, because selected == 0 means the
'..' entry, and every directory has a '..' entry, so it will be found.)
This fixes https://savannah.gnu.org/bugs/?47812.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When during searching we look at the keyboard, then don't look at
just the first keystroke, but check if there are more, and if so,
check each one until we find a Cancel -- or until all keystrokes
have been consumed and we can continue.
This fixes the first half of https://savannah.gnu.org/bugs/?47438.
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.
Also remove the item about one Replacement Character per invalid UTF-8
sequence, because how many bytes form a sequence? Two? Three? Four?
Better just put one Replacement Character per invalid byte, like is
done now.
When fixing a misspelling and not answering 'All' (but 'Yes' or 'No'),
the chance is quite substantial that one will type y or n at the end of
the next word. Diminish this chance by showing for a moment a message
on the statusbar.
Partitioning the file makes the undo system lose track, so that undoing
things has a good chance of losing data. Instead, just make sure that
the region is marked "backwards", with current at the top and the mark
at the bottom, and then let the replace loop take care of not going
outside of the marked region.
This also has the effect that if the marked region fits entirely on the
screen, or all the misspellings are onscreen, then the screen will not
be scrolled at all. Which makes for a smooth experience.
This fixes https://savannah.gnu.org/bugs/?47836,
and fixes https://savannah.gnu.org/bugs/?45573.
Since nano-2.4.1, reading in or pasting a large piece of text would put
the cursor on the bottom line, leaving only one line of the non-read or
non-pasted text visible. This is different from the centering behavior
of Pico, and somewhat disorienting, as you can't see "where you are" any
more in relation to the file as it was.
So now center the cursor whenever the read or pasted text is larger than
the screen, but don't center it when the text fits entirely on the screen.
(The latter avoids the effect of the screen jumping unnecessarily when
inserting just a few lines while the cursor is near the bottom.)
To achieve this behavior: default to focusing, and temporarily set it to
FALSE when the focusing effect is unwanted.
This fixes https://savannah.gnu.org/bugs/?47841.
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.
When starting to replace misspelled words, pass the actual position
of the cursor instead of the position of the first found occurrence,
so that the cursor position will be updated for changed lengths.
This fixes https://savannah.gnu.org/bugs/?47834.
When verifying that a match is a separate word (during spell checking),
instead of first copying out the word, then passing the word, and then
measuring its length, just pass its length straigtaway.
When we're spell checking, we don't need a special mechanism to detect
we have come full circle: reaching the end-of-buffer means we're done.
So don't bother to reset came_full_circle when we're spell checking
(when begin == NULL) but simply ignore its value.
Add a global variable, 'present_path', so that 'cwd_tab_completion()'
knows where the user is in the browser, so that it can try completions
against names in that directory instead of always against names in the
current working directory (where nano was invoked).
This fixes https://savannah.gnu.org/bugs/?47234.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
The internal spell checker starts searching/replacing always at the top
of the buffer, so reaching the end of the buffer means we're done with
the current search/replace. This prevents the "Search Wrapped" message
from flashing over the statusbar at the end of a spelling replacement.
Commit 8704dde mistakenly removed this part of code -- it is not dead,
it is just that it will only fire when the user answered No at some of
the replacement prompts. So... when we've rereached the starting line,
a found occurrence is invalid when it is beyond the starting x (either
after or before it, dependending on the direction of search).
This fixes https://savannah.gnu.org/bugs/?47816.
Included files are meant to contain only syntax definitions; they may
not set or unset options, nor rebind keys, nor include other files.
This fixes https://savannah.gnu.org/bugs/?47391.
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.
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>
When finding a misspelled word, the length of the match is simply the
length of that word, and its span in columns is simply the number of
columns that it occupies. Compute it thus directly.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
When searching for a misspelled word takes a while, and the user
stops this search with ^C, then abort the spelling-checking session.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
that is taking too long. This fixes Savannah bug #47439.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5776 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(The measurable effect (during long searches, for example) is zero, though.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5773 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an operating directory is not the same as restricted mode.
(In restricted mode, the file browser is not available at all.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5772 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
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
a misspelled word twice. And deleting the piece of dead code that was meant
to do this. This fixes Savannah bug #47188.
When we've reached again the same line where we started and we find an
instance there, then this can only be /before or at/ the position from
where we started, otherwise we would have found it when we commenced
searching. And so... that little piece of dead code does absolutely
nothing -- it will never fire.
It's so nice... nano is full of Easter Eggs! :)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5760 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
using it when it's available (which it is on OS X systems).
This completes the fix for Savannah bug #47325.
Patch by Thomas Rosenau.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5759 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
been set to 'answer' in search_init() when 'answer' isn't empty, and when
'answer' /is/ empty we use 'last_search' anyway.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5755 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
deletion of words like the pressing of Backspace/Delete, so they don't
overwrite the lines you cut elsewhere and want to paste into the place
of the cut words.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5751 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and the next time a Search or Replace is run, this answer is overwritten
with an empty string.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5749 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
return with -2 when answer is empty, so when answer is empty
i cannot be zero.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5747 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
We will need this again when one day we make a toggle between
jumping to a directory and searching for a filename fragment,
just like the ^T toggle that exists in the Search / Go-to-line
menus. But for now, we don't need this.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5745 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
functions that could be executed -- other than the line-edition ones,
which are executed under do_prompt(). So the latter won't return
unless either it was cancelled or an answer was given. Also, if it
/had/ returned with a value bigger than zero, it tried to put back
the key sequence for do_gotolinecolumn_void(), which does not exist
in the MBROWSER menu, so this would not have done anything.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5744 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the idea that it might have something to do with 'end_regex'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5733 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
non-GNU systems. This is a partial fix for Savannah bug #47325.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5731 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not for every added color, thus saving some 15 microseconds.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5729 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a leading underscore as the only difference is not enough.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5726 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
comes first, so that a search can stop at the first match instead of always
having to run through the entire list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5716 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of the first syntax that matches a certain magic string
(forgotten in the previous commit).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5705 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
name given on the command line, not from the name of the target file.
This fixes Savannah bug #47307.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5703 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an rcfile ends or when an invalid syntax command is found.
This fixes Savannah bug #47207
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5696 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to file extensions, but also to header lines and magic strings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5690 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the first element, and the insertion of a new element) directly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5678 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And not minding when the column number is zero or negative.
This partially fixes Savannah bug #47131.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5669 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there is no need to put one in. Just trim the allocation.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5666 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Add ability to kill the trailing spaces when justifying
code. New nanorc option kill_spaces_on_wrap, we'll see
whether this warrants a command line flahg or not.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5664 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Note that openfile cannot be NULL here. And in case it is,
nano should crash because DEBUG is enabled.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5658 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when the first Tab added the part that all matches have in common.
So now two Tabs in a row will always show the list of possible
completions -- if there /are/ any completions. Which means that
a second Tab will either: 1) do nothing, when the name is complete
and exists; 2) beep, when nothing in the current directory starts
with the current string; 3) show the list of matches.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5656 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of in the given string. This fixes Savannah bug #47199.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5654 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
history. This fixes Savannah bug #47124 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5653 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #47129 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5647 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and also when it is the first and only line.
This fixes Savannah bug #47153 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5646 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because 'allow_cntrls == FALSE' meant that controls were being filtered.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5644 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
iteration through search matches: showing them centered when found offscreen.
This fixes Savannah bug #47127.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5641 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed), so that it no longer shows in the help screen nor in the file list.
This fixes Savannah bug #47126.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5640 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
error messages upon reentry. And, if there are any messages,
allowing the user a little time to read them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5632 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
With this option, nano would simply refuse to write to any symlinked file;
if anyone really used this option, they would certainly have complained.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5608 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
mentioning how to enter Unicode and that regular expressions are line oriented.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5605 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes a segfault reported in Savannah bug #47011.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5596 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
of the environment (which can lead to a root-owned .nano/ directory in
the invoking user's home directory). This addresses Ubuntu bug #1471459.
(See https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1471459.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5580 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
any more, not a SIGWINCH either. And deleting an always-FALSE 'if'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5577 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a setting or making an excursion to the file browser.
This fixes Savannah bug #46945.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5576 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(So that most likely not more than two hundred plus a handful
will be written out. This was the easiest to implement.)
See https://lists.gnu.org/archive/html/nano-devel/2016-01/msg00050.html.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5571 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #46904 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5567 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
There's a bunch of return cases where we don't free the new full filename
which leads to leaks when writing out new files. One way to reproduce:
$ rm -f foo
$ nano foo
<hit enter>
<ctrl+o to save>
<ctrl+x to exit>
-> memory leak
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5563 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #26977 -- a hang on start="^" end="$".
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5538 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed (for the sake of multiline regexes), instead of doing it always.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5524 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed, before doing a redraw of the current line.
This fixes Savannah bug #46794
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5523 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
as it colours some things wrong and is a glutton on time.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5513 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
changed buffer after all, as the buffer may not have a name yet.
This fixes Savannah bug #46752.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5512 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there's an error saving history state at exit is pointless and annoying.
Just notify the user and move on.
Patch by Mike Frysinger, tweaked and extended by Benno.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5507 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Use plain AC_CHECK_HEADERS() instead, so ./configure will not check
for magic.h and zlib.h when --disable-libmagic is given.
Patch by Christian Weisgerber.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5505 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
routine isn't getting something from somewhere but just converting it.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5503 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And making the checking for an impatient user into a separate routine.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5501 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not just for the first. This fixes Savannah bug #46511.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5500 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
four different places. It is not a problem that the history routines
also use these functions, as history nodes will never equal filebot.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5491 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Users who want an immediate save, can bind the function 'savefile'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5489 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when trying to undo edits after an indentation change.
This works around Savannah bug #46591.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5474 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
making mistakes) when trying to undo edits after a justification.
This works around Savannah bug #45531.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5473 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Original file by Arturo Borrero Gonzalez.
This addresses Debian bug #805288.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5465 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Note that there can only be colorstrings when there /is/ a syntax,
so there is no need to check for the latter here.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5452 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
also when the coloured part is horizontally scrolled off.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5451 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
directly on the statusbar instead of as an undid or redid message.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5442 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and checking for this just once for every burst of keystrokes.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5439 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
command line does not exist. This fixes Savannah bug #46503.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5436 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
ncurses for the keycodes. This addresses Debian bug #800681.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5434 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This now mirrors unlink_opennode() and delete_opennode().
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5433 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
override the value of a "set fill" option in an rcfile.
This fixes Savannah bug #46492.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5428 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because the latter behaves differently depending on the setting of autoindent.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5400 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(Finally I understood what valgrind was complaining about.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5398 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
more symmetrical: wrapped in add_undo() + update_undo() where needed.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5390 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and recalculating the mark's x coordinate only when the mark comes after it.
Also correcting the recalculation in one case.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5384 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
last action. Necessary for when typing text is broken by an undo+redo.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5379 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
writing out the file immediately, without prompting.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5378 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
'u->mark_begin_lineno' is being used as the length of the insertion.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5375 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of to the beginning of the preceding word, to match the
behaviour of Pico and of most other editors. It also rewrites
the entire routine.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5372 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
as that is the only known situation where things go wrong. This spares
all regular text a significant slowdown.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5370 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Apparently there is /some/ state somewhere after all. Don't have time
now to figure out where exactly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5369 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
nor bothering with a separate initialization function when it's used only once.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5365 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Appending, Prepending, making Backups, and opening the File Browser.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5357 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(It will always be false, so it is apparently unneeded.)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5355 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
has not been built in, since the default values are quite usable.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5348 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
without adding confusing single quotes to the Info document.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5346 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the standard order, and giving the Savannah URL for bug reporting.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5344 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
--version, and to distinguish it more from the description of ^G.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5337 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to clarify some keys and to see which ones can be rebound.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5336 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
from the cursor to the preceding or succeeding word start.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5334 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
two superfluous checks for the definition of a formatter.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5325 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
first asking for its name. Patch was suggested by Seiya Nuta.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5318 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
opening an empty buffer when the name of a directory is specified.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5304 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and avoiding warnings about too large bit shifts.
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5303 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Removing an unneeded condition -- 'added_magicline' can only be
true when NO_NEWLINES isn't.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5297 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
at the end-of-file; just adding a token undo item to be able to put the
cursor back at the very tail of the file.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5285 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
before trying to use this multidata -- when a file is inserted, all
its lines will not have any multidata associated with them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5266 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
backspacing at the tail of the file no longer has any efffect.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5263 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an end earlier. This helps with Python's triple-quoted strings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5247 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
for an answer becomes zero. The answer will instead wrap to the
next line, which does not look nice but is better than crashing.
Patch by Mahyar Abbaspour.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5235 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
for all three cases: setting the string and then positioning the cursor.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5230 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
happens but only when checking for keyboard input. It now reports the
SIGWINCH via a special key value to the calling routine, to allow not
only the main editor but also the help viewer and the file browser to
adapt their display to the new size.
Patch by Mahyar Abbaspour, somewhat edited by Benno.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5228 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
before finding a unused filename takes an annoying amount of time.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5225 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and in the bargain getting rid of the need to calculate the
number of digits in UINT_MAX.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5224 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
canonical path instead of against the path the user gave.
This fixes Savannah bug #44288, reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5218 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
because the first sounds too much like "found_whole" to me.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5216 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
terminated, to prevent the displaying of ghost characters.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5206 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Help Viewer and the File Browswer, to mimic the behaviour of these keys
in file viewers and web browsers.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5201 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Adding a new function to glue together the invocation-error string.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5199 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
about the Savannah page, based on Benno's excellent suggestion.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5196 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to the effective and consistent first_file() and last_file().
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5191 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
unrequested search after having performed their function.
Fixes Savannah bug #44790.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5190 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
doing the replacings in situ in the current one, to fix an undo bug.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5189 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And condensing the renamed function, and making it void because
the result isn't used anyway.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5187 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of at the bottom or top, to show it in context.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5170 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
for any change in length of the region's last line.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5169 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to fix compilation with --disable-speller.
This fixes Savannah bug #44607.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5168 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/text.c (do_alt_speller): timestamp can just be a __time_t.
Fixes compilation on win32.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5153 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
but one character (possibly multibyte).
This fixes Savannah bug #42175.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5148 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
but only as far back as such a character can possibly be.
Speedup suggested by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5147 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to prevent do_undo() from falling over when trying to renumber emptiness.
Patch basically by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5137 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
of "header" and "magic" -- those regexes are not optional.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5132 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
for syntax highlighting, as suggested by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5129 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/cut.c (do_cut_text): Make sure to set modified even when
using --enable-tiny.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5112 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
switch_to_prevnext_buffer() to support message passthrough
when trying to lock files using multibuffer.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5105 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (open_buffer): Check here for locking and properly
handle choosing to not open a file when locked instead of in
open_file(). Fixes Savannah bug 42373 reported by Benno Schulenberg
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5104 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* New formatter code to support syntaxes like
go which have tools to automatically lint and reformat the text for
you (gofmt), which is lovely. rcfile option formatter, function
text.c:do_formatter() and some other calls.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5100 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Original patch from Savannah patch #8573 by Daniel Vrátil.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5096 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the program, instead of just a direct call via "/bin/program".
Doing this for Shell scripts, and for Python, Perl and Ruby.
This fixes Savannah bug #43270 reported by Kitty.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5095 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
an 'empty (sub)expression' error on MacOS X.
This fixes Savannah bug #42929.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5091 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to French manpages.
* doc/man/fr/nano.1, doc/man/fr/rnano.1, doc/man/fr/nanorc.5: Recode
as UTF-8.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5071 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
APT methods.
* doc/syntax/debian.nanorc: Apply the syntax to apt/sources.list.d/
entries as well, as reported by Rodolphe Pelloux-Prayer.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5070 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
undoing a cut or paste. And fixing two memory leaks.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5067 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
it is not merely a warning, it also activates a workaround.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5065 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
text additions that caused automatic line breaks.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5064 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (do_lockfile, open_file): If locking fails,
allow the lock failure message to be preserved AND
preserve the filename passed on the cmdline. Fixes
Savannah bug #42668.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5059 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (do_lockfile): Check whether the directory
of the file we're trying to lock exists, and make the
resulting error message more intuitive. Fixes
Savannah bug 42639 by bens.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5056 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(that is, when CUT_TO_END is set) properly.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5054 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And starting to use this to make the code a bit cleaner.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5050 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
file-searching capabilities again and all provisions for them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5048 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
confusion with CUT_TO_END, which is about end-of-line.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5041 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the corresponding Arrow key stop working (producing a character instead).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5040 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
having them declared everywhere and passing them around endlessly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5039 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
do not try to find one, because that would lead to the magic
database being searched, which slows down startup a lot.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5037 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when undoing line deletions at file's end.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5033 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
then it's for a function that is an empty placeholder, so executing it will
not do anything anyway. Handling the one exception (do_gotolinecolumn_void)
specially, just like the other one (do_cancel) already is.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5029 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
documenting 'tofiles' and 'flipnewbuffer', and correcting the
description of 'gototext' (not being about the file browser).
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5015 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to reduce the slight confusion with DIR meaning directory.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5013 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and removing an unneeded iteration of cutbottom.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5008 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
make sure openfile->filebot is updated.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5007 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
make sure openfile->filebot is updated.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5006 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
where the cut started, and not at the bottom of the file.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5005 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a position from history. This fixes Savannah bug #42538.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5003 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the histories of search/replace strings and cursor positions.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4988 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
as suggested by Mike Frysinger, plus some other tweaks.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4977 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when --tempfile was given and the current buffer has no name.
This fixes Savannah bug #41750. Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4974 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #38378, reported by Alan Hourihane.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4967 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
where it was when the cut was made.
Patch by Mark Majeres, edited by Benno Schulenberg.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4966 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
If wished, the user can unbind them. This fixes Savannah bug #42456.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4964 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
reinserted into the keyboard buffer. This fixes Savannah bug #42092.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4959 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
into the keyboard buffer. And not continuing but getting out when there is a
spurious mouse event. Continuing would result in the cutbuffer being cleared
upon the next cut. These two changes together fix Savannah bug #42326.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4956 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
line numbers are long, x positions unsigned long.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4950 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
empty string but checking for the terminating '\0'.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4949 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
And undoing line wraps together with their causal text additions, and not as
separate actions because the user did not make them.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4945 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
cursor should be in a slightly but significantly different position.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4944 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
null_at(), adding a cast, and using an unsigned type for a length.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4939 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/syntax/default.nanorc: Can't do trailing spaces in the
default syntax or it will hilight the spaces as you type
them into a new file, which for non-programming is infuriating.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4935 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
deleting a newline and any other character.
Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4934 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/chars.c (addstrings): Needs to be available even on
non-utf-8 sustems.
* nano-regress: Added --disable-utf8 to regression check
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4933 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/syntax/mutt.nanorc: Include Benno's awesome signature
matcher, modified slightly to also work for quoted sigs.
* doc/syntax/default.nanorc: Be far more gentle with something
which affects every file which doesn't match another syntax, and
the user may not be able to override if their distro turns on
highlighting by default.\
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4929 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/winio.c (edit_refresh): wredrawln() is not supported under
slang.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4918 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and handling multibyte characters correctly.
*Patch by Mark Majeres.*
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4908 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
the character in the final column will be displayed properly.
Bug was introduced five days ago. Patch by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4905 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
New file, originally from Aapo Rantalainen,
but heavily edited, extended, and improved.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4901 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and improving the comments -- all for apt's sources list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4898 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
using 'size_t' instead of 'int' for line lengths.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4895 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and mentioning the name of the terminal-tickling character (NBSP).
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4894 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
pastes. This fixes many undo problems and Savannah bug #25585.
*Patch by Mark Majeres.*
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4893 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
reminders for Python, and trim some trailing spaces from Fortran.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4864 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
also freeing the regexes for libmagic results and headerlines.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4862 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/rcfile.c (parse_color_names): Redefine false and true to
their appropriate macro names so --with-slang works (slangv2 anyway).
* src/text.c (do_linter): Care about whether user cancelled the file
save (cancel the operation) versus justy said no (continue but don't
save the file). Also doupdate() after statusbar message that
linter is being invoked and blank the shortcuts to draw the eye.
Also allow user to cancel at the "open in a new buffer" prompt.
New function lint_cleanup(). Fixes Savannah bug 42203.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4855 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and adding the still missing section on rebinding keys.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4854 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
on the ones after ^T (Speller/Linter) will work again correctly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4848 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
adding the "header" command,
tweaking some wording and formatting,
and trimming some duplicate introductory information.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4839 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
in the help lines, and grouping them as far as possible per menu.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4829 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
making them also group and pair nicely in the tiny version.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4825 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and add missing "prevpage"/"nextpage" in nanorc man page.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4818 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
also when the PrevPage and NextPage functions are bound to meta keys.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4810 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
adding and tweaking some comments, and removing an unneeded 'if'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4771 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
on the command line as a new file. Patch by Hans Alves.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4754 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
blank lines. Patch by David Lawrence Ramsey was lightly tweaked.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4750 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Tweaked version of file submitted by Robert Clausecker.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4748 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
in order to preserve ^Space and M-Space, so these can be unbound.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4747 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
to change its description to Unjustify at the appropriate moment.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4739 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
compilation should fail if they are needed and not defined.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4738 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Trimming some trailing whitespace, and fixing some misspellings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4698 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
grouping function pairs more tightly, bundling restricted stuff,
and deleting an unused item.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4691 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
issues from silently creeping in. Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4671 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* global.c (first_sc_for) - Return raw keystrokes last, so
they will not be displayed if there are F-key or Meta keys
mapped for an item in the shortcut list.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4642 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* global.c (shortcut_init) - Don't actually free the shortcut
list, since the next pass via justifying will then remove
all custom shortcuts. Fixed bug discovered by Benno Schulenberg.
* text.c (do_linter) - Remove some unused variables to quiet
-pedanic -Wall.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4637 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
without softwrap. And adding a few more NANO_TINY wrappings.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4633 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* global.c (shortcut_init) - fix an issue with the split
do_research() setup when using --enable-tiny
* rcfile.c (parse_linter) - Allow linter to be unset using ""
* rcfile.c - Allow syntaxes to be extended via "extendsyntax"
directive. Color, header, magic and linter should all be
able to be extended. Man page updates for nanorc(5).
* doc/nanorc.sample.in - Document 'set quiet'
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4630 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* new linter functionality. rcfile option "linter"
* src/global.c (shortcut_init) - Actually free the sclist
if it was allocated before.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4600 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/nano.c (copy_from_filestruct) - Check explicitly for mark being set when
trying to partition, as we shouldn't be messing with the x address, etc.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4585 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/winio.c (set_modified) - Check for a filename before we bother trying to lock
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4584 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/texinfo/nano.texi - Change '@sp4' since makeinfo 5.1 hates the
lack of spacing. Fixes Savannah bug 40103 repored by flapane@Savannah.
Also change SVN status to non-binary so diffs work.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4583 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/global.c (strtokeytype) - Check for lower-case 'f' for defining F-key
sequences for consistency (previously was two checks for upper case F). Fixes
bug 40815 reported by David Binderman <dcb314@Savannah>.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4581 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/global.c (first_sc_for) - try and more consistently display keystrokes,
useful when the user has re-binded a bunch of them.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4579 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
a marked file (especially that would give it the wrong stat info). Part
2 of issue reported by Benno Schulenberg.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4575 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (do_insertfile): Check for saved cursor position when inserting a
file as well. Fixes Savannah bug 38600 reported by Craig Barnes.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4574 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Revert r4547 as we should have a new release and the overlap code is not yet
ready for public consumption.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4569 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* configure.ac: Make ncurses checking to set $LIBS and check the ncursesw lib
actually works before defaulting to it over ncurses! Shock!
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4567 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
whether their target system support GNU-style word boundaries or not.
Originally reported by dave festing.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4566 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/text.c (do_histify): Don't allow sigwinch to be received while justifying
as that puts us into a wacky state. Fixess crash on justify by Joshua Rogers.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4565 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* configure.ac: Make ncursesw checking dependent on the presence of ncursesw.h,
since without the header files we can't compile.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4564 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/utils.c (parse_num): Initalize errno before calling strtol(). Fixes issue
where trying to go to a line number too long will break legitimate goto-lines
for the remainder of the editing session, reported by Joshua Rogers.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4563 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* configure.ac: Check for ncursesw5-config and base $CPPFLAGS based on it.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4562 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* configure.ac, src/nano.h: Make search for ncursesw more generalized.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4561 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
on the statusbar that we couldn't do it if the user modifies the file.
Changes to do_lockfile and write_lockfile to check for EACCESS and change
the return value of the functions (0 instead of -1)
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4550 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/*: Introduce (basic) vim-style file locks. Does not allow vim to recover
our files, and doesn't yet support setting the file as modified; just lets a
vim user know we're editing a file. Commands line "-G" or "--locking", nanorc
option "locking". New functions src/files.c:do_lockfile(), write_lockfile(),
and delete_lockfile().
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4549 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/*: Fix overlapping strings highlighting each other. new variables in edit_draw
(slmatcharray, pbegin, paintok), new logic (with repeated setting od values in the
array but its BFI after all). FIXME: Need to create a new 'overlap'
* src/*: Fix a silly issue with the argument to nregcomp, as it's confusing to the caller
* src/nano.h: Change the color types to a compiler macro (COLORWIDTH), may not actually
even be worth doing, but someday who knows how wide a color curses implementation might
be, and maybe we'll even start checking for it in autoconf!
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4547 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* text.c (do_enter): Only increment totsize by the auto-indented amount, size the previous line's size was
already counted. Fixes bug reported by Robert Spanjaard.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4544 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/syntax/Makefile.am: Finally get around to sorting the syntax file list
2011-05-08 Matthew Wild <mattj100@Savannah>
* doc/syntax/spec.nanorc: New lua syntax highlighting config
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4543 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* po/*: Sync latest translation fixes, add an update_linguas.sh script. Rename
existing update.pl to update_sources.pl to make it more specific.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4541 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* color.c (color_update): Add check for whether the file even exists
before we try to run the magic check on it. Fixes error messages to stderr
when reading in files that don't exist, reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4540 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* color.c (color_update): Remove unneeded debugging message from
libmagic commit. Fixed extra messages going to stderr reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4539 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Change RAW in function_type enum to RAWINPUT, to fix compilation on AIX,
reported by Richard G Daniel <skunk@iskunk.org>.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4535 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Fix some more severe warnings from 'g++ -pedantic', from patch originally
by Eitan Adler <lists@eitanadler.com>
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4534 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* color.c (nfreeregex): Fix that we were trying to set the pointer passed by value
to NULL. Fixes crashes on file save reported by Ken Tyler and Matthieu Lejeune.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4532 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
so do_research will succeed without needing to manually load the last seach in. Fixes
bug reported by Matt "ML" at gmail.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4531 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* New saved cursor position history option. Command line option -P or --poslog, rc file
entry "poslog". Search history changes to ~/.nano/search_history, cursor position log
is ~/.nano/filepos_history. Added checks to move the legacy .nano_history file to the new
location. Several new functions to files.c: load_poshistory(), save_poshistory(),
check_poshistory(), update_poshistory(), and reworking of histfilename(). New FAQ entry
4.15 discussing the change and offering an interoperability workaround.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4530 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Initial libmagic implementation, adapted from Eitan Adler <eitanadlerlist@gmail.com>.
New nanorc entry "magic" to enable this functionality, nanorc file and man page updates.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4528 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This does add 20KB to nano's executable size but it gets rid of a lot of indirection
that makes people stomach turn. There are several new stub functions and need of more
tidying as a result of this.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4527 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (write_file) - Fix problems with writing the backup file (albeit interactively)
with new function prompt_failed_backupwrite(), allows more secure handling of problems
with failing to write the backup file compared to 'allow_insecure_backup'.
* winio.c (edit_redraw): Removed unused variable
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4526 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Add a section to the FAQ about using nanorc on Win32 systems.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4522 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Add check for RESTRICTED mode back to speller, suspend and insert file
routines, since adding key bindings broke the fact that they should be
disabled in restricted mode. Fixes Savannah bug 31625 reported by
Charlie Somerville.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4519 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* New option allow_insecure_backup, allows the previous security
fixes for backup files to be overridden if you're really positive
you want to. Fixes Savannah bug 29732 by Brian Szymanski <skibrianski>.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4508 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (write_file): Don't even try to chown() the backup
file unless we're root, since it's probably going to fail if
we're editing a file we don't own. Fixes Savannah bug
29514: [nano 2.2.2] backup should ignore chown errors.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4507 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/man/nano.1,nanorc.5: Remove the backup file warnings now
that a sufficient security fix exists for the backup file code.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4502 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (wirte_file): Don't set current_stat when tmp == TRUE, check
whether current_stat is set when trying to use it, and don't do the
modification check if the filename changed, since we have no way
of knowing about it in that case. Fixes Savannah bug 29392, reported
by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4500 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* text.c (do_alt_speller): Skip invoking the alt speller if the file size
is 0 bytes. Fixes Savannah bug 29393 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4499 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (do_writeout): Better security fixes for backup file writing,
mangled from submission by Dan Rosenberg <dan.j.rosenberg at gmail>.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4496 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (do_writeout): Previous fixes should not cause a crash
when saving a new file. Discovered by Mike Frysinger <vapier@gentoo.org>.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4494 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/man/nano.1,nanorc.5: Add warnings about using backup
mode as root due to the Dan Rosenberg security analysis.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4493 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* files.c (do_writeout): Expand modification check to include both the
original file's device ID and inode number as reasons to warn the
user that the file has been modified. Based on security article on nano
by Dan Rosenberg.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4490 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* nano.c (page_stdin et al): Don't attempt to reset/reopen the terminal
settings when reading stdin if it was aborted with SIGINT. May fix Savannah
bug 29114 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4489 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* doc/syntax/c.nanorc: Add additional support for #include_next and #pragma
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4488 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
smooth scroll mode, as previous fixes would otherwise cause the cursor to not
really be moved to the stop of the screen.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4485 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* configure.ac, nano.c (handle_sigwinch): Create check for whether LINES and
COLS can safely be redefined. Fixes compilation issues with cygwin, and likely
with newer versions of ncurses, fixes Savannah bug 28984 repoted by Andy Koppe
and Eric Oliver via mailing list.
* winio.c (get_mouseinput) - fix stray semicolon in code, also reported in
bug 28984.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4484 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
2010-03-07 19:35:46 +00:00
153 changed files with 84361 additions and 58088 deletions
AC_MSG_RESULT([Using $CURSES_LIB_NAME as the curses library])
fi
AC_CHECK_LIB([$CURSES_LIB_NAME], use_default_colors, AC_DEFINE(HAVE_USE_DEFAULT_COLORS, 1, [Define this if your curses library has the use_default_colors() command.]))
[AC_DEFINE(HAVE_USE_DEFAULT_COLORS, 1, [Define this if your curses library has the use_default_colors() command.])],
[], [$CURSES_LIB])
AC_CHECK_LIB([$CURSES_LIB_NAME], [key_defined],
[AC_DEFINE(HAVE_KEY_DEFINED, 1, [Define this if your curses library has the key_defined() command.])],
[], [$CURSES_LIB])
dnl Parse any configure options.
@@ -486,7 +585,7 @@ if test "x$GLIB_LIBS" != "x"; then
LDFLAGS="$LDFLAGS $GLIB_LIBS"
fi
if test x$enable_utf8 != xno && \
if test "x$enable_utf8" != xno && \
test x$CURSES_LIB_WIDE = xyes && \
test x$ac_cv_func_iswalnum = xyes && \
test x$ac_cv_func_iswpunct = xyes && \
@@ -499,14 +598,14 @@ if test x$enable_utf8 != xno && \
test x$ac_cv_func_wcwidth = xyes; then
AC_DEFINE(ENABLE_UTF8, 1, [Define this if your system has sufficient UTF-8 support (a wide curses library, iswalnum(), iswpunct(), iswblank() or iswspace(), nl_langinfo, mblen(), mbstowcs(), mbtowc(), wctomb(), and wcwidth()).])
else
if test x$enable_utf8 = xyes; then
if test "x$enable_utf8" = xyes; then
AC_MSG_ERROR([
*** UTF-8 support was requested, but insufficient UTF-8 support was
*** detected in your curses and/or C libraries. Please verify that your
*** slang was built with UTF-8 support or your curses was built with
*** wide character support, and that your C library was built with wide
*** character support.])
elif test x$enable_utf8 != xno; then
elif test "x$enable_utf8" != xno; then
AC_MSG_WARN([
*** Insufficient UTF-8 support was detected in your curses and/or C
*** libraries. If you want UTF-8 support, please verify that your slang
@@ -516,10 +615,36 @@ else
fi
fi
if test x$color_support = xyes; then
# now check for the end of word boundary support (/< and />)
AC_MSG_CHECKING([for GNU-style word boundary regex support])
<ahref="#2.4">2.4. By subversion (for the brave).</a></p></blockquote>
<ahref="#2.4">2.4. By GIT (for the brave).</a></p></blockquote>
<h2><ahref="#3">3. Installation and Configuration</a></h2>
<blockquote><p><ahref="#3.1">3.1. How do I install the RPM or DEB package?</a><br>
<ahref="#3.2">3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</a><br>
<ahref="#3.3">3.3. Why does everything go into /usr/local?</a><br>
<ahref="#3.4">3.4. I get errors about 'bindtextdomain','gettext', and/or 'gettextdomain'. What can I do about it?</a><br>
<ahref="#3.5">3.5. nano should automatically run strip on the binary when installing it!</a><br>
<ahref="#3.6">3.6. How can I make the executable smaller? This is too bloated!</a><br>
<ahref="#3.7">3.7. Tell me more about this multibuffer stuff!</a><br>
<ahref="#3.8">3.8. Tell me more about this verbatim input stuff!</a><br>
<ahref="#3.9">3.9. How do I make a .nanorc file that nano will read when I start it?</a></p></blockquote>
<ahref="#3.9a">3.9a. How do I make a .nanorc file that nano will read when I start it?</a><br>
<ahref="#3.9b">3.9b. How about in Win32?</a></p></blockquote>
<h2><ahref="#4">4. Running</a></h2>
<blockquote><p><ahref="#4.1">4.1. How do I open a file with a name beginning with '+' from the command line?</a><br>
<ahref="#4.2">4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</a><br>
@@ -38,14 +39,11 @@
<ahref="#4.5">4.5. How do I type the F13-F16 keys shown in the help browser? My keyboard only has F1-F12!</a><br>
<ahref="#4.6">4.6. nano crashes when I type <insert keystroke here>!</a><br>
<ahref="#4.7">4.7. nano crashes when I resize my window. How can I fix that?</a><br>
<ahref="#4.8">4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</a><br>
<ahref="#4.9">4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</a><br>
<ahref="#4.10a">4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</a><br>
<ahref="#4.10b">4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</a><br>
<ahref="#4.11">4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
<ahref="#4.12">4.12. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.13">4.13. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</a><br>
<ahref="#4.14">4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</a></p></blockquote>
<ahref="#4.8">4.8. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</a><br>
<ahref="#4.9">4.9. I've compiled nano with color support, but I don't see any color when I run it!</a><br>
<ahref="#4.10">4.10. How do I make nano my default editor (in Pine, mutt, etc.)?</a><br>
<ahref="#4.11">4.11. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</a><br>
<ahref="#4.12">4.12. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</a></p></blockquote>
<h2><ahref="#5">5. Internationalization</a></h2>
<blockquote><p><ahref="#5.1">5.1. There's no translation for my language!</a><br>
<ahref="#5.2">5.2. I don't like the translation for <x> in my language. How can I fix it?</a><br>
@@ -60,16 +58,17 @@
<ahref="#7.2">7.2. I want to send the development team a big load of cash (or just a thank you).</a><br>
<ahref="#7.3">7.3. How do I submit a bug report or patch?</a><br>
<ahref="#7.4">7.4. How do I join the development team?</a><br>
<ahref="#7.5">7.5. Can I have write access to the subversion tree?</a></p></blockquote>
<ahref="#7.5">7.5. Can I have write access to the GIT tree?</a></p></blockquote>
<h2><ahref="#8">8. ChangeLog</a></h2>
<hrwidth="100%">
<h1><aname="1"></a>1. General</h1>
<h2><aname="1.1"></a>1.1 About this FAQ</h2>
<blockquote><p>This FAQ was originally written and maintained by Chris Allegretta <<ahref="mailto:chrisa@asty.org">chrisa@asty.org</a>>, who also happens to be the creator of nano. It was then maintained by David Lawrence Ramsey <<ahref="mailto:pooka109@gmail.com">pooka109@gmail.com</a>>. Maybe someone else will volunteer to maintain this FAQ someday, who knows...</p></blockquote>
<h2><aname="1.2"></a>1.2. How do I contribute to it?</h2>
<blockquote><p>Your best bet is to send it to the nano email address, <ahref="mailto:nano@nano-editor.org">nano@nano-editor.org</a> and if it is useful enough it will be included in future versions.</p></blockquote>
<h2><aname="1.3"></a>1.3. What is GNU nano?</h2>
<blockquote><p>GNU nano is designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aims to "emulate Pico as closely as possible and perhaps include extra functionality".</p></blockquote>
<blockquote><p>GNU nano is designed to be a free replacement for the Pico text editor, part of the Pine email suite from <ahref="http://www.washington.edu/pine/">The University of Washington</a>. It aims to "emulate Pico as closely as possible and then include extra functionality".</p></blockquote>
<h2><aname="1.4"></a>1.4. What is the history behind nano?</h2>
<blockquote><p>Funny you should ask!</p>
<p><b>In the beginning...</b></p>
@@ -78,52 +77,51 @@
<p>The <ahref="http://www.debian.org/">Debian GNU/Linux</a> distribution, known for its strict standards in distributing truly "free" software (i.e. software with no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but the versions available at the time were not truly free software in the <ahref="http://www.gnu.org/philosophy/free-sw.html">GNU</a> sense of the word.</p>
<p><b>The event...</b></p>
<p>It was in late 1999 when Chris Allegretta (our hero) was yet again complaining to himself about the less-than-perfect license Pico was distributed under, the 1000 makefiles that came with it and how just a few small improvements could make it the Best Editor in the World (TM). Having been a convert from Slackware to Debian, he missed having a simple binary package that included Pine and Pico, and had grown tired of downloading them himself.</p>
<p>Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help text display, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the (hopefully) stable state it is today.</p>
<p>Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help text display, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the (hopefully) stable state it is in today.</p>
<p>In February 2001, nano was declared an official GNU program by Richard Stallman. nano also reached its first production release on March 22, 2001.</p></blockquote>
<h2><aname="1.5"></a>1.5. Why the name change from TIP?</h2>
<blockquote><p>On January 10, 2000, TIP was officially renamed to nano because of a namespace conflict with another program called 'tip'. The original 'tip' program "establishes a full duplex terminal connection to a remote host", and was included with many older Unix systems (and newer ones like Solaris). The conflict was not noticed at first because there is no 'tip' utility included with most GNU/Linux distributions (where nano was developed).</p></blockquote>
<h2><aname="1.6"></a>1.6. What is the current version of nano?</h2>
<blockquote><p>The current version of nano *should* be 2.2.0. Of course, you should always check the nano homepage to see what the latest and greatest version is.</p></blockquote>
<blockquote><p>The current version of nano <i>should</i> be <b>2.7.4</b>. Of course, you should always check the <ahref="https://nano-editor.org/">nano homepage</a> to see what the latest and greatest version is.</p></blockquote>
<h2><aname="1.7"></a>1.7. I want to read the man page without having to download the program!</h2>
<p>You can also have a look at the <ahref="ftp://ftp.debian.org/debian/pool/main/n/nano/">Package Pool</a> to see all the available binary and source packages.</p>
<p>Note that versions < 0.9.10 are probably not for those wanting to get serious work done, so if you are using Debian 2.2, check that you have updated to 2.2r3, which comes with nano 0.9.23. If you're tracking unstable, you probably have the newest version already.</p></blockquote>
<h2><aname="2.4"></a>2.4. By subversion (for the brave).</h2>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use subversion to download the current source code. <b>Note:</b> believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see <ahref="http://svn.savannah.gnu.org/viewvc/trunk/nano/README.SVN?root=nano&view=markup">the nano SVN document</a> for info on anonymous SVN access to the nano source.</p></blockquote>
</blockquote>
<h2><aname="2.4"></a>2.4. By GIT (for the brave).</h2>
<blockquote><p>For the 'bleeding edge' current version of nano, you can use GIT to download the current source code. <b>Note:</b> believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see <ahref="http://git.savannah.gnu.org/cgit/nano.git/tree/README.GIT">the nano GIT document</a> for info on anonymous GIT access to the nano source.</p></blockquote>
<hrwidth="100%">
<h1><aname="3"></a>3. Installation and Configuration</h1>
<h2><aname="3.1"></a>3.1. How do I install the RPM or DEB package?</h2>
<blockquote><p>It's simple really! As root, type <b>rpm -Uvh nano-x.y.z-1.i386.rpm</b> if you have a RedHat-ish system or <b>dpkg -i nano_x.y.z-1.deb</b> if you have a Debian-ish system, where <b>x.y.z</b> is the release of nano. There are other programs to install packages, and if you wish to use those, knock yourself out.</p></blockquote>
<h2><aname="3.2"></a>3.2. Compiling from source: WHAT THE HECK DO I DO NOW?</h2>
<blockquote><p>Okay, take a deep breath, this really isn't hard. Unpack the nano source with a command like:</p>
<p><b>tar -zxvf nano-x.y.z.tar.gz</b></p>
<p>If you get error messages about the -z option, try this:</p>
<p><b>gzip -dc nano-x.y.z.tar.gz | tar xvf -</b></p>
<p>(again, where x.y.z is the version number in question). Then you need to run configure with any options you might want (if any).</p>
<p><b>tar -xvf nano-x.y.z.tar.gz</b></p>
<p>Then you need to run <b>configure</b> with any options you might want (if any).</p>
<p>The average case is this:</p>
<p><b>cd nano-x.y.z/</b><br>
<b>./configure</b><br>
@@ -133,77 +131,75 @@
<blockquote><p>Well, that's what the <b>configure</b> script defaults to. If you wish to change this, simply do this:</p>
<p><b>./configure --prefix=/usr</b></p>
<p>to put nano into /usr/bin when you run <b>make install</b>.</p></blockquote>
<h2><aname="3.4"></a>3.4. I get errors about 'bindtextdomain', 'gettext', and/or 'gettextdomain'. What can I do about it?</h2>
<blockquote><p>Try doing a <b>./configure --with-included-gettext</b> and see if that solves your problem. You may need to do a <b>make clean; make</b> to get it to work fully.</p></blockquote>
<h2><aname="3.5"></a>3.5. nano should automatically run strip on the binary when installing it!</h2>
<blockquote><p>Actually, it does, but you have to use <b>make install-strip</b>. The default make install does not, and will not, run strip automatically.</p></blockquote>
<h2><aname="3.6"></a>3.6. How can I make the executable smaller? This is too bloated!</h2>
<blockquote><p>Actually, there are several parts of the editor that can be disabled. You can pass arguments to the <b>configure</b> script that disable certain features. Here's a brief list:</p>
<b>--disable-wrapping</b> Disable all wrapping of text (and -w flag)
<b>--disable-mouse</b>Disable mouse support (and -m flag)
<b>--disable-operatingdir</b> Disable setting of operating directory</pre>
<p>There's also the <b>--enable-tiny</b> option which disables everything above, as well as some larger chunks of the program (like the marker code that you use Control-^ to select with). Also, if you know you aren't going to be using other languages you can use <b>--disable-nls</b>to disable internationalization and save a few K to a few dozen K depending on if you have locale support on your system. And finally there's always good old <b>strip</b> to strip all debugging code and code that exists in libraries on your system.</p>
<p>If, on the other hand, you can't live without bells and whistles, you could try:</p>
<pre>
<b>--enable-extra</b>Enable extra features, currently only easter eggs
<b>--enable-nanorc</b> Enable use of .nanorc files
<b>--enable-color</b> Enable color and syntax highlighting
<b>--enable-multibuffer</b>Enable having multiple file buffers open
<b>--enable-all</b> Enable all of the above features
<b>--disable-wrapping-as-root</b>
Disable text wrapping by default when the user is
root</pre></blockquote>
<b>--disable-histories</b> Disable the saving of search strings and cursor positions
<b>--disable-wordcomp</b>Disable the word completion function
<b>--disable-wrapping</b> Disable all hard-wrapping of text</pre>
<p>There's also the <b>--enable-tiny</b>option which disables everything above, as well as some larger chunks of the program (like the marker code that you use with Control-^ to select text). Also, if you know you aren't going to be using other languages, you can use <b>--disable-nls</b> to disable internationalization and save a few K to a few dozen K depending on whether you have locale support on your system. And finally, there's always good old <b>strip</b> to strip all debugging code and code that exists in libraries on your system.</p>
<p>With <b>--disable-wrapping-as-root</b> you can disable any hard-wrapping by default when the user is root, useful to prevent accidentally changing long lines in system configuration files.</p>
</blockquote>
<h2><aname="3.7"></a>3.7. Tell me more about this multibuffer stuff!</h2>
<blockquote><p>To use multiple file buffers, you must be using nano 1.1.0 or newer, and you must have configured nano with <b>--enable-multibuffer</b>(use nano -V to check). Then when you want to enable inserting a file into its own buffer instead of into the current file, just hit <b>Meta-F</b>, then insert the file as normal with <b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>--multibuffer</b> or <b>-F</b> flag when you invoke nano.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b> and <b>Meta-></b> keys, or more easily with <b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one file buffer open, the ^X shortcut will say "Close", instead of the normal "Exit" when only one buffer is open.</p></blockquote>
<blockquote><p>To use multiple file buffers, you must not have configured nano with <b>--disable-multibuffer</b>nor with <b>--enable-tiny</b> (use <b>nano -V</b> to check the compilation options). Then when you want to insert a file into its own buffer instead of into the current file, just hit <b>Meta-F</b>, then insert the file as normal with <b>^R</b>. If you always want files to be loaded into their own buffers, use the <b>--multibuffer</b> or <b>-F</b> flag when you invoke nano.</p>
<p>You can move between the buffers you have open with the <b>Meta-<</b> and <b>Meta-></b> keys, or more easily without holding Shift:<b>Meta-,</b> and <b>Meta-.</b> (clear as mud, right? =-). When you have more than one file buffer open, the ^X shortcut will say "Close", instead of the normal "Exit" when only one buffer is open.</p></blockquote>
<h2><aname="3.8"></a>3.8. Tell me more about this verbatim input stuff!</h2>
<blockquote><p>To use verbatim input, you must be using nano 1.3.1 or newer. When you want to insert a literal character into the file you're editing, such as a control character that nano usually treats as a command, first press <b>Meta-V</b>. (If you're not at a prompt, you'll get the message "Verbatim Input".) Then press the key(s) that generate the character you want.</p>
<p>Alternatively, if you've enabled Unicode support (see section <ahref="#5.3">5.3</a>), you can press <b>Meta-V</b> and then type a six-digit hexadecimal code from 000000 to 10FFFF (case-insensitive), and the character with the corresponding value will be inserted instead. The prompt will change to "Unicode Input" when you do this.</p></blockquote>
<h2><aname="3.9"></a>3.9. How do I make a .nanorc file that nano will read when I start it?</h2>
<blockquote><p>It's not hard at all! But, your version of nano must have been compiled with <b>--enable-nanorc</b>, and again must be version 1.1.12 or newer (use nano -V to check your version and compiled features). Then simply copy the <b>nanorc.sample</b> that came with the nano source or your nano package (most likely in /usr/doc/nano) to .nanorc in your home directory. If you didn't get one, the syntax is simple. Flags are turned on and off by using the word <b>set</b> and the getopt_long flag for the feature, for example "set nowrap" or "set suspend".</p></blockquote>
<blockquote><p>When you want to insert a literal character into the file you're editing, such as a control character that nano usually treats as a command, first press <b>Meta-V</b> (if you're not at a prompt, you'll get the message "Verbatim Input" on the statusbar), then press the key(s) that generate the character you want.</p>
<p>Alternatively, if you've enabled Unicode support (see section <ahref="#5.3">5.3</a>), you can press <b>Meta-V</b> and then type a six-digit hexadecimal code (from 000000 to 10FFFF, case-insensitive), and the character with the corresponding value will be inserted. The statubar will change to "Unicode Input: ......" when you do this.</p></blockquote>
<h2><aname="3.9a"></a>3.9a. How do I make a .nanorc file that will be read when I start nano?</h2>
<blockquote><p>It's not hard at all! But, your nano must <b>not</b> have been compiled with <b>--disable-nanorc</b>. Then simply copy the <b>sample.nanorc</b> that came with the nano source or your nano package (most likely in /usr/doc/nano) to .nanorc in your home directory. If you didn't get one, the syntax of the file is simple. Flags are turned on and off by using the words<b>set</b> and <b>unset</b> plus the long option name for the feature. For example,"set nowrap" or "set smarthome".</p></blockquote>
<h2><aname="3.9b"></a>3.9b. How about in Win32?</h2>
<blockquote><p>If you're using the official nano .zip file and have extracted all the files, you should take the file nano.rc and place it somewhere on your Win32 system (for example, if you have write permission to do so, at the top of C:\). Then you must create an Environment variable called HOME which points to the directory where you put nano.rc. In Windows XP, you can get to Environment variables by right-clicking "My Computer" either on the desktop or in the Start Menu, and selecting Properties. This should bring up the System Properties panel. Then click the Advanced Tab, and there should be a button called Environment Variables. Click that to bring up the Environment Variables section. Now, under User Variables you should be able to click the New button, and make a new Variables Name called HOME, with the Variable Value of whatever path you copied nano.rc into (just the directory name; don't add nano.rc onto the end).</p>
<p>We're still working on documentation for enabling syntax highlighting on Win32; please bear with us.</p>
<p>Note that the nano.rc file must remain Unix-formatted in order for nano to understand it. In other words, you should probably use only nano to edit its config file. Other programs like Wordpad and Notepad will convert the file to DOS format when saving, and the latter does not even properly read Unix-formatted files to begin with.</p></blockquote>
<hrwidth="100%">
<h1><aname="4"></a>4. Running</h1>
<h2><aname="4.1"></a>4.1. How do I open a file with a name beginning with '+' from the command line?</h2>
<blockquote><p>If a commandline option that begins with '+' is followed by another option, the former is always treated as a starting line and column number and the latter is always treated as a filename. If a commandline option that begins with '+' isn't followed by another option, it's always treated as a filename. Examples:</p>
<blockquote><p>If a command-line option that begins with '+' is followed by another option, the former is always treated as a starting line and column number, and the latter is always treated as a filename. If a command-line option that begins with '+' isn't followed by another option, it's always treated as a filename. Examples:</p>
<p>To open '+filename.txt' starting on line 1: <b>nano +filename.txt</b><br>
To open '+filename.txt' starting on line 10: <b>nano +10 +filename.txt</b><br>
To open '+filename.txt' starting on line 1, column 20: <b>nano +,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 10, column 20: <b>nano +10,20 +filename.txt</b><br>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 10 (if nano has been compiled with multibuffer support): <b>nano +1 +filename.txt +20 filename.txt</b></p></blockquote>
To open '+filename.txt' starting on line 1 and 'filename.txt' starting on line 40 (if nano has been compiled with multibuffer support): <b>nano +1 +filename.txt +40 filename.txt</b></p></blockquote>
<h2><aname="4.2"></a>4.2. Ack! My Backspace/Delete/Enter/Meta/double bucky key doesn't seem to work! What can I do?</h2>
<blockquote><p>Try setting your $TERM variable to 'vt100'. nano doesn't yet support every term entry under the sun.</p>
<p>Bourne shell users (bash and sh): <b>export TERM=vt100</b><br>
C Shell users (tcsh and csh): <b>setenv TERM vt100</b></p></blockquote>
<h2><aname="4.3"></a>4.3. Ack! My numeric keypad's keys don't work properly when NumLock is off! What can I do?</h2>
<blockquote><p>You can use the <b>-K</b> or <b>--rebindkeypad</b> options on the command line, or add the line <b>set rebindkeypad</b> to your .nanorc. However, nano's mouse support won't work properly if you do any of these things.</p></blockquote>
<blockquote><p>You can use the <b>-K</b> or <b>--rebindkeypad</b> option on the command line, or add the line <b>set rebindkeypad</b> to your .nanorc. However, nano's mouse support won't work properly if you do any of these things.</p></blockquote>
<h2><aname="4.4"></a>4.4. Ack! When I hold down a Meta key combination for a while, the character of the held key gets inserted now and then. What gives?</h2>
<blockquote><p>This is a bug in the terminal, not in nano. When a key is repeating faster than nano can process it, the keyboard buffer becomes full and starts dropping incoming keystrokes. Unfortunately, it doesn't just drop whole keystrokes; it can also drop parts of multibyte key combinations, resulting in nano's receiving a wrong key.</p></blockquote>
<h2><aname="4.5"></a>4.5. How do I type the F13-F16 keys shown in the help browser? My keyboard only has F1-F12!</h2>
<blockquote><p>It depends on the terminal type you're using. On some terminals, such as the FreeBSD console, xterm, konsole, and gnome-terminal, Shift-F1 to Shift-F4 will generate F13 to F16. On other terminals, such as the Linux console, rxvt, and Eterm, Shift-F3 to Shift-F6 will generate F13 to F16.</p></blockquote>
<h2><aname="4.6"></a>4.6. nano crashes when I type <insert keystroke here>!</h2>
<blockquote><p>If you aren't trying some bizarre keystroke combination with some bizarre $TERM entry, chances are you have found a bug. You are welcome to submit it to the <ahref="mailto:nano-devel@gnu.org">nano-devel</a> list or to<ahref="mailto:nano@nano-editor.org">nano@nano-editor.org</a>.</p></blockquote>
<blockquote><p>If you aren't trying some bizarre keystroke combination with some bizarre $TERM entry, chances are you have found a bug. You are welcome to submit it to the <ahref="mailto:nano-devel@gnu.org">nano-devel</a> list or in the<ahref="https://savannah.gnu.org/bugs/?group=nano">bug tracker</a> on Savannah.</p></blockquote>
<h2><aname="4.7"></a>4.7. nano crashes when I resize my window. How can I fix that?</h2>
<blockquote><p>Older versions of nano had this problem, please upgrade to a newer version (at least 0.9.9 would be great, 0.9.12 is recommended).</p></blockquote>
<h2><aname="4.8"></a>4.8. [version 1.3.12 and later] I'm using glibc 2.2.3, and nano crashes when I use color support or do regular expression searches. How can I fix that?</h2>
<blockquote><p>It's a bug in glibc 2.2.3. You should upgrade to at least glibc 2.2.4.</p></blockquote>
<h2><aname="4.9"></a>4.9. [version 1.1.12 and earlier] Why does nano show ^\ in the shortcut list instead of ^J?</h2>
<blockquote><p>The help (^G) and justify (^J) function were among the last to be written. To show the improvements that nano had over Pico (go to line # and replace), ^_ and ^\ were put on the shortcut list. Later, ^G came back in place of ^_ as it proved to be very valuable for new Unix users. If you use the <b>-p</b> option to nano (or hit Meta-P) you will get the same shortcuts at the bottom as Pico.</p></blockquote>
<h2><aname="4.10a"></a>4.10a. [version 1.1.12 and earlier] When I type in a search string, the string I last searched for is already in front of my cursor! What happened?!</h2>
<blockquote><p>In nano version 0.9.20, the default is to have a completely consistent user interface across all user input functions. This means that regardless of whether you're being asked for a filename to insert or write, or a string to search for, the previous value is already inserted before the cursor. If you prefer the old behavior, use the Pico emulation mode (-p or --pico) or just hit Meta-P while in nano (see the ^G help text for more details).</p></blockquote>
<h2><aname="4.10b"></a>4.10b. [version 1.1.99pre1 and later] Hey, the search string behavior has reverted, it's now like Pico, what happened to the consistency?</h2>
<blockquote><p>It was decided that consistency was nice, but people are used to Pico's inconsistent behavior. Also, in version 1.1.99pre1, search and replace history was introduced. If you wish to edit your previous search/replace entry (or any previous entry), you can do so by hitting the up arrow to cycle through your history. This method allows the best of both worlds: You don't need to erase the previous string if you want to enter a new one, but you can with one keystroke recall previous entries for editing. Therefore there is now no "Pico mode", nano is and has always been a Pico <b>clone</b>, and clones by default should be compatible.</p></blockquote>
<h2><aname="4.11"></a>4.11. How do I make nano my default editor (in Pine, mutt, etc.)?</h2>
<blockquote><p>Older versions of nano had this problem. Please upgrade to version 2.7.0 or newer.</p></blockquote>
<h2><aname="4.8"></a>4.8. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</h2>
<blockquote><p>You have the autoindent feature turned on. Hit Meta-I to turn it off, paste your text, and then hit Meta-I again to turn it back on.</p></blockquote>
<h2><aname="4.9"></a>4.9. I've compiled nano with color support, but I don't see any color when I run it!</h2>
<blockquote><p>If you want nano to actually use color, you have to specify the color configurations you want it to use in your .nanorc. Several example configurations are in the <b>doc/syntax</b> subdirectory of the nano source, which are normally installed to <b>/usr/local/share/nano</b>. To enable all of them, uncomment the line <b># include "/usr/local/share/nano/*.nanorc"</b> in your nanorc. See also section <ahref="#3.9a">3.9a</a>.</p></blockquote>
<h2><aname="4.10"></a>4.10. How do I make nano my default editor (in Pine, mutt, etc.)?</h2>
<blockquote><p>You need to make nano your $EDITOR. If you want this to be saved, you should put a line like this in your <b>.bashrc</b> if you use bash (or <b>.zshrc</b> if you believe in zsh):</p>
<p><b>export EDITOR=/usr/local/bin/nano</b></p>
<p>or, if you use tcsh, put this in your <b>.cshrc</b> file:</p>
<p><b>setenv EDITOR /usr/local/bin/nano</b></p>
<p>Change /usr/local/bin/nano to wherever nano is installed on your system. Type "which nano" to find out. This will not take effect until the next time you login. So log out and back in again.</p>
<p>Change /usr/local/bin/nano to wherever nano is installed on your system. Type "which nano" to find out. This will not take effect until the next time you login. So log out and back in again.</p>
<p>Then, on top of that, if you use Pine, you must go into setup (type <b>S</b> at the main menu), and then configure (type <b>C</b>). Hit Enter on the lines that say:</p>
<p><b>[ ] enable-alternate-editor-cmd</b><br>
<b>[ ] enable-alternate-editor-implicitly</b></p>
@@ -211,116 +207,125 @@
<p>If you're a mutt user, you should see an effect immediately the next time you log in. No further configuration is needed. However, if you want to let people know you use nano to compose your email messages, you can put a line like this in your <b>.muttrc</b>:</p>
<p><b>my_hdr X-Composer: nano x.y.z</b></p>
<p>Again, replace x.y.z with the version of nano you use.</p></blockquote>
<h2><aname="4.12"></a>4.12. I've compiled nano with color support, but I don't see any color when I run it!</h2>
<blockquote><p>If you want nano to actually use color, you have to specify the color configurations you want it to use in your .nanorc. Some example configurations are in the <b>nanorc.sample</b> that comes with the nano source or your nano package. See Section <ahref="#3.9">3.9</a>.</p></blockquote>
<h2><aname="4.13"></a>4.13. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</h2>
<h2><aname="4.11"></a>4.11. How do I select text for or paste text from the clipboard in an X terminal when I'm running nano in one and nano's mouse support is turned on?</h2>
<blockquote><p>Try holding down the Shift key and selecting or pasting the text as you normally would.</p></blockquote>
<h2><aname="4.14"></a>4.14. When I paste text into a document, each line gets indented further than the last. Why does nano do this, and how can I avoid it?</h2>
<blockquote><p>You have the autoindent feature turned on. Hit Meta-I to turn it off, paste your text, and then hit Meta-I again to turn it back on.</p></blockquote>
<h2><aname="4.12"></a>4.12. On startup I get a message that says "Detected a legacy nano history file". Now older nano versions can't find my search history!</h2>
<blockquote><p>In nano 2.3.0, cursor-position history was introduced, and both history files now reside in a .nano subdirectory in your home directory. A newer nano will move an existing search-history file to this new location so it can continue to be used. This means that if you then try and use an earlier version of nano, it will be unable to see your current search history. To fix this, run the following command:<br>
</p><p>The "migration service" (moving the search-history file to its new location) will be deleted from nano in early 2018.</p></blockquote>
<hrwidth="100%">
<h1><aname="5"></a>5. Internationalization</h1>
<h2><aname="5.1"></a>5.1. There's no translation for my language!</h2>
<blockquote><p>On June of 2001, GNU nano entered the <ahref="http://translationproject.org/html/welcome.html">Free Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask <ahref="http://translationproject.org/team/">your language team</a> to translate nano, or better still, join your team and do it yourself. Joining a team is easy. You just need to ask the <ahref="mailto:coordinator@translationproject.org">TP coordinator</a> to add you to your team, and send a <ahref="http://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a> (this is necessary as nano is an official GNU package, but it does <b>not</b> mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is very easy. Just grab the <b>nano.pot</b> file from the latest and greatest nano distribution (it's in the <b>po/</b>directory) and translate each line into your native language on the <b>msgstr</b> line. When you're done, you should send it to the TP's central po repository.</p></blockquote>
<blockquote><p>In June 2001, GNU nano entered the <ahref="http://translationproject.org/html/welcome.html">Translation Project</a> and since then, translations should be managed from there.</p>
<p>If there isn't a translation for your language, you could ask <ahref="http://translationproject.org/team/">your language team</a> to translate nano, or better still, join that team and do it yourself. Joining a team is easy. You just need to ask the team leader to add you, and then send a <ahref="http://translationproject.org/disclaim.txt">translation disclaimer to the FSF</a> (this is necessary as nano is an official GNU package, but it does <b>not</b> mean that you transfer the rights of your work to the FSF, it's just so the FSF can legally manage them).</p>
<p>In any case, translating nano is very easy. Just grab the latest <b>nano.pot</b> file listed on <ahref="http://translationproject.org/domain/nano.html">nano's page</a>at the TP, and translate each<b>msgid</b> line into your native language on the <b>msgstr</b> line. When you're done, you should send it to the TP's central po repository.</p></blockquote>
<h2><aname="5.2"></a>5.2. I don't like the translation for <x> in my language. How can I fix it?</h2>
<blockquote><p>The best way would probably be to e-mail the person listed in the <code>Last-Translator:</code> field in the <b><your_language>.po</b> file with your suggested corrections and they can make the changes reach the nano-devel list.</p></blockquote>
<blockquote><p>The best way would probably be to send an e-mail to the team's mailing listed mentione in the <code>Language-Team:</code> field in the <b><your_language>.po</b> file with your suggested corrections, and then they can make the changes reach the nano-devel list.</p></blockquote>
<h2><aname="5.3"></a>5.3. What is the status of Unicode support?</h2>
<blockquote><p>In version 1.3.12 or later, Unicode should be usable. With your terminal, locale (LC_ALL and similar environment variables), and encoding configured to properly support UTF-8, you should be able to enter and save Unicode text.</p></blockquote>
<blockquote><p>Since versions 1.3.12, Unicode should be usable. With your terminal, locale (LC_ALL and similar environment variables), and encoding configured to properly support UTF-8, you should be able to enter and save Unicode text.</p></blockquote>
<hrwidth="100%">
<h1><aname="6"></a>6. Advocacy and Licensing</h1>
<h2><aname="6.1"></a>6.1. Why should I use nano instead of Pico?</h2>
<blockquote><p>There are many reasons to use nano instead of Pico. A more complete list can be found at the <ahref="http://www.nano-editor.org/">nano homepage</a>.</p></blockquote>
<blockquote><p>There are many reasons to use nano instead of Pico. A more complete list can be found at the <ahref="https://nano-editor.org/">nano homepage</a>.</p></blockquote>
<h2><aname="6.2"></a>6.2. Why should I use Pico instead of nano?</h2>
<blockquote><p>Again, check out the <ahref="http://www.nano-editor.org/">nano homepage</a> for a good summary of reasons. It really is a matter of personal preference as to which editor you should use. If you're the type of person who likes using the original version of a program, then Pico is the editor for you. If you don't mind sacrificing mailer integration with Pine, and are looking for a few more features, as well as a 'better' license in terms of adding your own changes, nano is the way to go.</p><p>Note that the last of these no longer applies to the new version of Pine, <ahref="http://www.washington.edu/alpine/">Alpine</a>, which is under the Apache License, version 2.0.</p></blockquote>
<blockquote><p>Again, check out the <ahref="https://nano-editor.org/">nano homepage</a> for a good summary of reasons. It really is a matter of personal preference as to which editor you should use. If you're the type of person who likes using the original version of a program, then Pico is the editor for you. If you don't mind sacrificing mailer integration with Pine, and are looking for a few more features, as well as a 'better' license in terms of adding your own changes, nano is the way to go.</p><p>Note that the last of these no longer applies to the new version of Pine, <ahref="http://www.washington.edu/alpine/">Alpine</a>, which is under the Apache License, version 2.0.</p></blockquote>
<h2><aname="6.3"></a>6.3. What is so bad about the older Pine license?</h2>
<blockquote><p>The U of W license for older versions of Pine and Pico is not considered truly Free Software according to both the Free Software Foundation and the <ahref="http://www.debian.org/social_contract#guidelines">Debian Free Software Guidelines</a>. The main problem regards the limitations on distributing derived works: according to UW, you can distribute their software, and you can modify it, but you can not do both, i.e. distribute modified binaries.</p></blockquote>
<h2><aname="6.4"></a>6.4. Okay, well, what mail program should I use then?</h2>
<blockquote><p>If you are looking to use a Free Software program similar to Pine, and Emacs is not your thing, you should definitely take a look at <ahref="http://www.mutt.org/">mutt</a>. It is a full-screen, console based mail program that actually has a lot more flexibility than Pine, but has a keymap included in the distribution that allows you to use the same keystrokes as Pine would to send and receive mail. It's also under the GNU General Public License, version 2.0.<P>
Of course, due to the license change you can now use the <AHREF="http://www.washington.edu/alpine/">Alpine distribution</A> of PINE as it is now considered Free Software, but you would be sacrificing many of nano's features to do so.</p></blockquote>
<blockquote><p>There are three mailing lists for nano hosted at <ahref="http://savannah.gnu.org/">Savannah</a>, info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<blockquote><p>There are three mailing lists for nano hosted at <ahref="http://savannah.gnu.org/">Savannah</a>: info-nano, help-nano and nano-devel. info-nano is a very low traffic list where new versions of nano are announced (surprise!). help-nano is for getting help with the editor without needing to hear all of the development issues surrounding it. nano-devel is a normally low, sometimes high traffic list for discussing the present and future development of nano. Here are links to where you can sign up for a given list:</p>
<h2><aname="7.2"></a>7.2. I want to send the development team a big load of cash (or just a thank you).</h2>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="http://www.nano-editor.org/dist/v2.2/BUGS">bug</a> in the program or implement a <ahref="http://www.nano-editor.org/dist/v2.2/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<blockquote><p>That's fine. Send it <ahref="mailto:nano-devel@gnu.org">our way</a>! Better yet, fix a <ahref="https://savannah.gnu.org/bugs/?group=nano">bug</a> in the program or implement a <ahref="https://nano-editor.org/dist/latest/TODO">cool feature</a> and send us that instead (though cash is fine too).</p></blockquote>
<h2><aname="7.3"></a>7.3. How do I submit a bug report or patch?</h2>
<blockquote>
<p>The best place to submit bugs is to the <AHREF="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</A> as you can check whether the bug you are submitting has already been submitted.
<p>The best place to submit bugs is to the <ahref="https://savannah.gnu.org/bugs/?group=nano">Savannah bug tracker</a> as you can check whether the bug you are submitting has already been submitted.
<p>Please submit patches for nano via the <ahref="https://savannah.gnu.org/patch/?group=nano">Savannah project's patch manager</a> for the nano project.</p></blockquote>
<h2><aname="7.4"></a>7.4. How do I join the development team?</h2>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given SVN write access after awhile. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h2><aname="7.5"></a>7.5. Can I have write access to the subversion tree?</h2>
<blockquote><p>Re-read Section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
<h2><aname="8"></a>8. ChangeLog</h2>
<blockquote><p>2009/11/30 - Update various bits for nano 2.2.x. (DLR)<br>
2009/11/18 - Typo fix. (j.mader@gmail.com)<br>
2008/03/16 - Update docs to refer to subversion instead of CVS, add more words about Alpine, and refer to Savannah for bugs and patches. (chrisa)<br>
2007/12/09 - Add minor punctuation and wording fixes, and update various sections to account for Alpine. (DLR)<br>
2007/08/26 - Update links to the Free Translation Project. (DLR)<br>
2007/07/29 - Update RPM links for nano 2.0.x. (DLR)<br>
2007/04/18 - Add a new section 4.14 to explain how autoindent affects pasted text. (John M. Gabriele, minor tweaks by DLR)<br>
2007/04/04 - Update email address. (DLR)<br>
2007/01/01 - Update section 4.1 to describe how to open files with names beginning with '+' at specified columns as well as lines. (DLR)<br>
2006/11/25 - Add miscellaneous wording and capitalization fixes. (DLR)<br>
2006/10/28 - Update various links for the 2.0 branch of nano. (DLR)<br>
2006/10/06 - Update the question in section 4.13 to match the version of it in the answer section. (DLR)<br>
2006/07/25 - Update section 5.3 again to not state "the latest development version" before 1.3.12, as it's no longer accurate. Also add some minor spacing fixes. (DLR)<br>
2006/06/12 - Update section 5.3, due to the display fix for two-column Unicode characters. (DLR)<br>
2006/06/05 - Add a new section 4.8, and move all section 4 entries after it down one number, to explain how to deal with glibc 2.2.3's crashes involving extended regular expressions. (DLR)<br>
2006/06/04 - Add minor punctuation, wording, and typo fixes. (DLR)<br>
2006/05/27 - Update section 3.8 to mention the new "Unicode Input" prompt, and how Unicode input only works when Unicode support is enabled. (DLR)<br>
2006/05/12 - Remove section 4.4, and move all section 4 entries after it up one number, since it no longer applies. Meta-] and Meta-[ are no longer used to indent and unindent marked text, since they require that the bracket matching key change to Ctrl-], which is used as the telnet escape key (found by Chris). Also, make the link to the nano CVS page a bit more readable. (DLR)<br>
2006/05/08 - Add a new section 4.5, and move all section 4 entries after it down one number, to explain a problem that can occur when holding down keys to generate Meta sequences. Also add a few more capitalization and wording fixes. (Benno Schulenberg, minor tweaks by DLR)<br>
2006/05/01 - Add a new section 4.4, and move all section 4 entries after it down one number, to explain how to deal with problems typing Meta-[. Also add a few capitalization and wording fixes. (DLR)<br>
2006/04/14 - Clarify section 1.4: help menu -> help text display. (DLR, suggested by Benno Schulenberg)<br>
2006/03/16 - Update the Free Translation Project's address, change the character set to UTF-8, and remove broken links to contributed RedHat nano packages. (DLR)<br>
2005/11/21 - Clarify section 5.3 to better explain how to enable Unicode support, and remove the mention of quirks, since they turned out to not be a nano problem. (Mike Frysinger and DLR)<br>
2005/11/19 - Add a new section 5.3 to explain the status of nano's Unicode support. (Mike Frysinger, minor tweaks by DLR)<br>
2005/08/27 - Update email address. (DLR)<br>
2005/08/10 - Add a new section 4.3, and move all section 4 entries after it down one number, to explain how to deal with numeric keypad problems. (DLR)<br>
2005/08/08 - Update section 3.8 to mention that verbatim input mode now takes a six-digit hexadecimal number. (DLR)<br>
2005/07/04 - Update section 4.10 to mention that pasting from the X clipboard via the middle mouse button also works when the Shift key is used. (DLR)<br>
2005/06/15 - Update description of --enable-extra, and add missing line breaks. (DLR)<br>
2005/06/13 - Minor capitalization and wording fixes. (DLR)<br>
2005/06/08 - Updated section 1.1 to mention the current maintainer. (DLR)<br>
2005/03/09 - Added question about opening files with names beginning with '+'s, and added a few more miscellaneous cosmetic fixes. (DLR)<br>
2005/01/03 - Removed now-inaccurate note about verbatim input's not working at prompts, and update its description to mention that it handles hexadecimal values now. (DLR)<br>
2004/11/21 - Listed sh as an example of a Bourne shell. (DLR)<br>
2004/11/05 - Fixed inaccuracy: Pico compatibility mode was made the default in nano 1.1.99pre1, not 1.2.2. Also added question about how to type F13-F16 on terminals lacking keys past F12 (suggested by Chris), question about how to select text for the clipboard in X terminals with nano's mouse support turned on (answer found by Joseph Birthisel), and misc. fixes and link updates. (DLR)<br>
2004/04/07 - Removed NumLock glitch question, as it's no longer needed. (DLR)<br>
2004/01/30 - Fixed inaccuracy: multibuffer mode was first in nano 1.1.0, not 1.1.12. (DLR)<br>
2003/12/31 - Added question about the new verbatim input function, and a few minor fixes. Removed reference to "set pico" (DLR).<br>
2003/07/02 - Added question about nano's not showing color when it's compiled with color support (DLR; suggested by Jordi).<br>
2003/02/23 - Updated RPM links for nano 1.2.x (DLR).<br>
2003/01/16 - Split section 4.5 into 4.5a and 4.5b for search string behavior. Added --enable-all docs.<br>
2002/12/28 - More misc. fixes (David Benbennick, DLR).<br>
2002/10/25 - Misc. fixes and link updates (DLR).<br>
2002/09/10 - Another typo fix (DLR).<br>
2002/05/15 - Typo fix (DLR).<br>
2001/12/26 - Misc. fixes (Aaron S. Hawley, DLR).<br>
2001/10/02 - Update for Free Translation Project.<br>
2000/11/28 - Added blurb about make install-strip.<br>
2000/11/19 - Changed Debian frozen to stable.<br>
2000/11/18 - Previous string display (4.5).<br>
2000/09/27 - Moved addresses to nano-editor.org.<br>
2000/06/31 - Initial framework.</p></blockquote>
<p>$Id$</p>
<blockquote><p>The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two, and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the Savannah development list and be given write access after awhile. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.</p></blockquote>
<h2><aname="7.5"></a>7.5. Can I have write access to the git tree?</h2>
<blockquote><p>Re-read section <ahref="#7.4">7.4</a> and you should know the answer.</p></blockquote>
<hrwidth="100%">
<h1><aname="8"></a>8. ChangeLog</h1>
<blockquote><p>
2017.01.09 - Delete some obsolete items and update a few others. (Benno)<br>
2016.04.17 - Update docs to refer to GIT instead of subversion. (Mike)<br>
2015.07.18 - More small fixes and updates. (Benno)<br>
2014.04.24 - A bunch of small fixes and updates. (Benno)<br>
2009.11.30 - Update various bits for nano 2.2.x. (DLR)<br>
2009.11.18 - Typo fix. (j.mader@gmail.com)<br>
2008.03.16 - Update docs to refer to subversion instead of CVS, add more words about Alpine, and refer to Savannah for bugs and patches. (Chris)<br>
2007.12.09 - Add minor punctuation and wording fixes, and update various sections to account for Alpine. (DLR)<br>
2007.08.26 - Update links to the Free Translation Project. (DLR)<br>
2007.07.29 - Update RPM links for nano 2.0.x. (DLR)<br>
2007.04.18 - Add a new section 4.14 to explain how autoindent affects pasted text. (John M. Gabriele, minor tweaks by DLR)<br>
2007.04.04 - Update email address. (DLR)<br>
2007.01.01 - Update section 4.1 to describe how to open files with names beginning with '+' at specified columns as well as lines. (DLR)<br>
2006.11.25 - Add miscellaneous wording and capitalization fixes. (DLR)<br>
2006.10.28 - Update various links for the 2.0 branch of nano. (DLR)<br>
2006.10.06 - Update the question in section 4.13 to match the version of it in the answer section. (DLR)<br>
2006.07.25 - Update section 5.3 again to not state "the latest development version" before 1.3.12, as it's no longer accurate. Also add some minor spacing fixes. (DLR)<br>
2006.06.12 - Update section 5.3, due to the display fix for two-column Unicode characters. (DLR)<br>
2006.06.05 - Add a new section 4.8, and move all section 4 entries after it down one number, to explain how to deal with glibc 2.2.3's crashes involving extended regular expressions. (DLR)<br>
2006.06.04 - Add minor punctuation, wording, and typo fixes. (DLR)<br>
2006.05.27 - Update section 3.8 to mention the new "Unicode Input" prompt, and how Unicode input only works when Unicode support is enabled. (DLR)<br>
2006.05.12 - Remove section 4.4, and move all section 4 entries after it up one number, since it no longer applies. Meta-] and Meta-[ are no longer used to indent and unindent marked text, since they require that the bracket matching key change to Ctrl-], which is used as the telnet escape key (found by Chris). Also, make the link to the nano CVS page a bit more readable. (DLR)<br>
2006.05.08 - Add a new section 4.5, and move all section 4 entries after it down one number, to explain a problem that can occur when holding down keys to generate Meta sequences. Also add a few more capitalization and wording fixes. (Benno Schulenberg, minor tweaks by DLR)<br>
2006.05.01 - Add a new section 4.4, and move all section 4 entries after it down one number, to explain how to deal with problems typing Meta-[. Also add a few capitalization and wording fixes. (DLR)<br>
2006.04.14 - Clarify section 1.4: help menu -> help text display. (DLR, suggested by Benno Schulenberg)<br>
2006.03.16 - Update the Free Translation Project's address, change the character set to UTF-8, and remove broken links to contributed RedHat nano packages. (DLR)<br>
2005.11.21 - Clarify section 5.3 to better explain how to enable Unicode support, and remove the mention of quirks, since they turned out to not be a nano problem. (Mike Frysinger and DLR)<br>
2005.11.19 - Add a new section 5.3 to explain the status of nano's Unicode support. (Mike Frysinger, minor tweaks by DLR)<br>
2005.08.27 - Update email address. (DLR)<br>
2005.08.10 - Add a new section 4.3, and move all section 4 entries after it down one number, to explain how to deal with numeric keypad problems. (DLR)<br>
2005.08.08 - Update section 3.8 to mention that verbatim input mode now takes a six-digit hexadecimal number. (DLR)<br>
2005.07.04 - Update section 4.10 to mention that pasting from the X clipboard via the middle mouse button also works when the Shift key is used. (DLR)<br>
2005.06.15 - Update description of --enable-extra, and add missing line breaks. (DLR)<br>
2005.06.13 - Minor capitalization and wording fixes. (DLR)<br>
2005.06.08 - Updated section 1.1 to mention the current maintainer. (DLR)<br>
2005.03.09 - Added question about opening files with names beginning with '+'s, and added a few more miscellaneous cosmetic fixes. (DLR)<br>
2005.01.03 - Removed now-inaccurate note about verbatim input's not working at prompts, and update its description to mention that it handles hexadecimal values now. (DLR)<br>
2004.11.21 - Listed sh as an example of a Bourne shell. (DLR)<br>
2004.11.05 - Fixed inaccuracy: Pico compatibility mode was made the default in nano 1.1.99pre1, not 1.2.2. Also added question about how to type F13-F16 on terminals lacking keys past F12 (suggested by Chris), question about how to select text for the clipboard in X terminals with nano's mouse support turned on (answer found by Joseph Birthisel), and misc. fixes and link updates. (DLR)<br>
2004.04.07 - Removed NumLock glitch question, as it's no longer needed. (DLR)<br>
2004.01.30 - Fixed inaccuracy: multibuffer mode was first in nano 1.1.0, not 1.1.12. (DLR)<br>
2003.12.31 - Added question about the new verbatim input function, and a few minor fixes. Removed reference to "set pico" (DLR).<br>
2003.07.02 - Added question about nano's not showing color when it's compiled with color support (DLR; suggested by Jordi).<br>
2003.02.23 - Updated RPM links for nano 1.2.x (DLR).<br>
2003.01.16 - Split section 4.5 into 4.5a and 4.5b for search string behavior. Added --enable-all docs.<br>
2002.12.28 - More misc. fixes (David Benbennick, DLR).<br>
2002.10.25 - Misc. fixes and link updates (DLR).<br>
2002.09.10 - Another typo fix (DLR).<br>
2002.05.15 - Typo fix (DLR).<br>
2001.12.26 - Misc. fixes (Aaron S. Hawley, DLR).<br>
2001.10.02 - Update for Free Translation Project.<br>
color brightcyan "\<(and|as|assert|break|class|continue|def|del|elif|else|except|exec|finally|for|from|global|if|import|in|is|lambda|not|or|pass|print|raise|return|try|while|with|yield)\>"
color brightgreen "['][^']*[^\\][']" "[']{3}.*[^\\][']{3}"
color brightgreen "["][^"]*[^\\]["]" "["]{3}.*[^\\]["]{3}"
color brightgreen start=""""[^"]" end=""""" start="'''[^']" end="'''"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
