"Press ENTER" prompt when edit file with long path

[J. Lewis Muir]

Hello!

In an 80-column terminal, when I invoke vim on an existing empty file
with a name that is 56 'x' characters, it displays the following prompt
before I can edit the file:

----
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 0 lines, 0 characters

Press ENTER or type command to continue
----

How can I stop it from doing that?

NOTE: The file has to exist for it to do this. If it's a new file that
Vim will create, Vim does not show the prompt.

It seems that it's being triggered by the message Vim is writing about
the file when the length of the message Vim writes exceeds 80 columns.
For example, it does not display the prompt if the file name is 55 'x'
characters.

Environment:

* OS: macOS Catalina 10.15.1
* Vim: 8.1, patches 1-2400 (Installed via Homebrew)

I'm hitting this all the time throughout the day in at least two use
cases.

The first is when using Vim as the editor for my email client, NeoMutt.
NeoMutt creates a temporary file for a new message that I compose, and,
at least on macOS, that file path is pretty long. For example:

----
/private/var/folders/05/c2k7bj3x0vv6p85skhxq86zm0000gp/T/neomutt-mink-502-88191-4572282957772858142
----

So, before I can compose each message, I get that prompt and have to
press ENTER.

The other use case is when using Vim as the editor for Mercurial. When
I make a commit, Mercurial creates a temporary file for the commit
message, and it too is long. For example:

----
/private/var/folders/05/c2k7bj3x0vv6p85skhxq86zm0000gp/T/hg-editor-4xe_jotf.commit.hg.txt
----

So, before writing every commit message, I have to press ENTER.

To reproduce this issue, do the following in an 80-column terminal in a
Bourne-like shell:

----
$ x56=$(dd if=/dev/zero bs=1 count=56 | tr '\0' x)
$ touch $x56
$ vim -u NONE $x56
----

Thank you!

Lewis

[Gary Johnson]

On 2019-12-10, J. Lewis Muir wrote:
> Hello!
>
> In an 80-column terminal, when I invoke vim on an existing empty file
> with a name that is 56 'x' characters, it displays the following prompt
> before I can edit the file:
>
> ----
> "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 0 lines, 0 characters
>
> Press ENTER or type command to continue
> ----
>
> How can I stop it from doing that?
>
> NOTE: The file has to exist for it to do this. If it's a new file that
> Vim will create, Vim does not show the prompt.

This looks like a new bug. The presence of the 't' flag in the
'shortmess' option should prevent this, and that flag is there by
default. I just verified that it used to work in 7.4.1689 and
8.0.1453 but is now broken in my 8.1.2352 (on Linux) as well as your
8.1.2400.

Regards,
Gary

[Gary Johnson]

I used git bisect and tested with

$ src/vim -N -u NONE ../xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

where the file had already been created, to determine that the
commit that introduced this bug was:

473952e85286eb9c6098801f1819981ba61ad153 is the first bad commit
commit 473952e85286eb9c6098801f1819981ba61ad153
Author: Bram Moolenaar <Br...@vim.org>
Date: Sat Sep 28 16:30:04 2019 +0200

patch 8.1.2094: the fileio.c file is too big

Problem: The fileio.c file is too big.
Solution: Move buf_write() to bufwrite.c. (Yegappan Lakshmanan,
closes #4990)

:100644 100644 2d05b4a3af6a96a04f446789b5c9ca69ab905e9c dfc06245e585e883459dfa04416addce91d3d8ce M Filelist
:040000 040000 506a68f58e09932cd2b29e2f3eaec5e16e197a9f b5166a4265c3536326785a13e29336e7f778448a M src

Regards,
Gary

[Yegappan Lakshmanan]

Hi,

The following change in the above commit might have caused this:

======================================================
- static void
+ void
filemess(
buf_T *buf,
char_u *name,
@@ -119,6 +39,7 @@ filemess(
int attr)
{
int msg_scroll_save;
+ int prev_msg_col = msg_col;

if (msg_silent != 0)
return;
@@ -138,6 +59,8 @@ filemess(
if (!msg_scroll) /* wait a bit when overwriting an error msg */
check_for_delay(FALSE);
msg_start();
+ if (prev_msg_col != 0 && msg_col == 0)
+ msg_putchar('\r'); // overwrite any previous message.
msg_scroll = msg_scroll_save;
msg_scrolled_ign = TRUE;
/* may truncate the message to avoid a hit-return prompt */
@@ -2512,7 +2435,11 @@ failed:
p = msg_may_trunc(FALSE, IObuff);
else
#endif
+ {
+ if (msg_col > 0)
+ msg_putchar('\r'); // overwrite previous message
p = (char_u *)msg_trunc_attr((char *)IObuff, FALSE, 0);
+ }
if (read_stdin || read_buffer || restart_edit != 0
|| (msg_scrolled != 0 && !need_wait_return))
/* Need to repeat the message after redrawing when:
======================================================

Another breakage was reported earlier by the above change and
fixed by "patch 8.1.2141: :tselect has an extra hit-enter prompt".

Regards,
Yegappan

[Bram Moolenaar]

I don't think it is related to that CL. The problem appears to be in
msg_puts_display(). When outputting the CR it thinks the text is going
to wrap, but it won't.

--
hundred-and-one symptoms of being an internet addict:
245. You use Real Audio to listen to a radio station from a distant
city rather than turn on your stereo system.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Gary Johnson]

I verified manually that the bug is not there in the previous
commit. I have no explanation.

I just built 8.1.2420. No bug. Thanks.

Regards,
Gary