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.

Make the failures to read or write a lock file into important messages,
so they will not be overwritten by the number of lines read.

The general mechanism for not allowing important messages to be overwritten
will take care of not overwriting warnings about failed file lockings.

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.

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.

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>

This restores things to the way they were before commit 36ec76a5.
Apparently all those refreshes are needed in some cases after all.

This fixes https://savannah.gnu.org/bugs/?47786.

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 41ed6907, 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.

Names could be strings of multibyte characters, so they could be more
than COLS - 1 bytes long and still be less than COLS - 1 columns wide.

Also unwrap or improve some comments.

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.

When a tilde is used in the name given at the ^R or ^O prompts, nano
expands it, but /not/ when a tilde is given on the command line (in
such a way that the shell leaves it as is).  Correct that asymmetry.

This fixes https://savannah.gnu.org/bugs/?44929
and fixes https://savannah.gnu.org/bugs/?47702
and fixes https://savannah.gnu.org/bugs/?47771.

Commit 36ec76a5 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.)

Because it is a little clearer, and it is what Pico does too.

This partly fixes https://savannah.gnu.org/bugs/?47721.

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.

Just let read_line() zero-terminate the intermediate buffer when
the line is complete.

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.

Also don't zero-terminate the matches in order to compare them,
but just limit the length of the comparison.

(This change will be made superfluous when we start using gnulib.)

This prevents getcwd() from failing on Android and thus completes the
fix for https://savannah.gnu.org/bugs/index.php?47659

.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>

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>

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>

So it will fit on the screen when using a standard 80-column terminal.

This fixes https://savannah.gnu.org/bugs/?47544,
and thus also http://gnats.netbsd.org/51010

.
Reported-by: Adrian Siekierka <asiekierka@gmail.com>
Reported-by: Matthew Hall <mhall@mhcomputing.net>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5779 35c25a1d-7b9e-4130-9fde-d3aeb78583b8