Blocking echo messages on startup result in blank screen

[ilyagr]

Steps to reproduce

With the latest prerelease, I run the following command (from a draft default diff tool config similar to jj-vcs/jj#6205, sorry for extraneous quotes):

Update: I changed this line to remove irrelevant backticks. They mess up the result in bash or zsh; I didn't notice because I use fish.

"gvim" "-f" "-d" "-u" "/dev/null" mkdocs-offline.yml mkdocs.yml "-c" "echohl WarningMsg" "-c" "echomsg \"Warning: using plain vimdiff as a diff editor is not recommended. See https://github.com/jj-vcs/jj/wiki/Vim for alternatives.\"" "-c" "echohl None"

(It doesn't matter which two files you'd be comparing, or if they even exist)

This results in a confusing blank screen instead of the expected message:

After pressing Enter, everything works.

Expected behaviour

In plain vim, I get:

"mkdocs-offline.yml" 19 lines, 724 bytes
"mkdocs.yml" 154 lines, 4992 bytes
Warning: using plain `vimdiff` as a diff editor is not recommended. See https://github.com/jj-vcs/jj/wiki/Vim for alternatives.
Press ENTER or type command to continue

Then, vim loads after I press ENTER.

Version of Vim and architecture

1-1251

Environment

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Mar 28 2025 09:26:05)
macOS version - arm64
Included patches: 1-1251
Compiled by GitHub Actions

How MacVim was installed

Downloaded from GitHub

Logs and stack traces

Vim configuration where issue is reproducable

No response

Issue has been tested with given configuration

• by running MacVim.app from GUI macOS interface
• by running vim/gvim/etc installed by MacVim
• by running other versions of vim (e.g. /usr/bin/vim)

Issue has been tested with no configuration

• by running mvim --clean (or gvim, supplied by MacVim distribution)
• by running vim --clean (in terminal, supplied by MacVim distribution)
• by running vim --clean (in terminal, other suppliers, e.g. /usr/bin/vim)

Other conditions

• The both Homebrew packages "vim" and "macvim" are installed

[ychin]

Let me take a look, but I think this is a bad interaction with the "Press Enter" mode in Vim and some recent resize changes in MacVim. Basically Vim's "Press Enter" mode is quite fragile in that if you resize the window, it will clear all the rendering instead of redrawing itself. This issue occurs when Vim is used in a terminal as well but MacVim may have triggered a resize event which caused this to happen.

Have you noticed this issue before (e.g. in r181) the current pre-release build (r181.1)? It would be nice to know when you have noticed that.

But as you noticed it's mostly a rendering / redraw issue in Vim and pressing enter will indeed fix the issue.

[ilyagr]

As of now, I haven't tried any other versions.

[ilyagr]

I tried using :echowin instead of :echomsg in that command line, but that didn't work with MacVim at all. I was going to ask if I should use it instead (e.g. if it has been around for long enough), but I guess not.

It might be the same issue with resizing, since after MacVim launches, manually using :echowin in it works, but the message gets cut off a bit.

[ychin]

echowin works. As you said it works if you type it manually. Either way it's not really the expected way to show an error message at launch so it's not going to be a good option regardless. (Edit: Actually I tried it and it seemed to work fine. What is the actual issue?)

Also, running your command seems to trigger some serious warning. Did you look at the terminal output and look at what it's saying? You are wrapping "vimdiff" as `vimdiff` and that's going to run vimdiff due to how most shells work and make everything unhappy. It's not like most terminal emulators understands markdown. Also, is there a reason why you are using -u /dev/null instead of -u NONE?

[ychin]

I think the issue here is multi-fold. You are using -u /dev/null which is equivalent to -u NONE which forces a press-enter prompt when using vimdiff (even without your messages) (see point (1) below), and it also enables scroll bars which causes a resize. The resize clips the press-enter prompt.

There are multiple things you could do here:

1. Don't use -u NONE. At least use -u DEFAULTS which has better behavior on start when using diff mode (just try both without your message commands and you will see what I mean). I think this is due to different shortmess settings. Alternatively, just respect user defaults and don't force it to something else.
2. You could use echowin after doing (1) above.
3. You could use :echomsg like before but set a timer of 0 seconds using timer_start so that the new message doesn't literally get called immediately and interfere with Vim's own output of the file being edited and resize.
4. Play around with messageopt to avoid hit-enter. That said this may have the issue of stomping user defaults.
5. You can also disable scroll bars to prevent the resize trigger which like above does have the issue of stomping user defaults.

I do want to fix Vim's Press Enter prompt to be more safe to terminal resizing but I think there are other things you could do in the meantime.

Btw, seems like the issue here is that jj defaults to vimdiff, but then you want it to warn when vimdiff is used as-is because it does not do folder diff? That seems like a mediocre default behavior to me, as defaults should work instead of throwing up an annoying error message. If vimdiff doesn't work at all, it should just not be allowed to launch with jj explaining why. If it works, then having this error message every time a user wants to use it is going to get old real fast. This "kind of works but I'll annoy the hell out of you" seems like half measures to me. Even if there are warning messages I think it's better to show them before Vim is launched to have a consistent way to do this. Once Vim is launched you should just let it do its thing and the user may have all sorts of weird configurations that you are not aware of that may interfere with your message injection. I don't use it though so it's up to you.

[ilyagr]

You are using -u /dev/null which is equivalent to -u NONE which forces a press-enter prompt when using vimdiff (even without your messages)

This was just to make sure my config doesn't affect the reproduction. I also tried --clean when I saw it recommended in the issue template.

The actual config doesn't have that option, and I get all the same problems.

If you want to play around with jj, here's what I was trying. edit-args is the important option.

[merge-tools.gvimdiff]
program = "gvim"
# `-d` enables diff mode. `-f` makes vim run in foreground even if it starts a GUI.
# The other options make sure that only the output file can be modified.
merge-args = ["-f", "-d", "$output", "-M", "$left", "$base", "$right",
              "-c", "wincmd J", "-c", "set modifiable", "-c", "set write",
              "-c", "/<<<<<</+2"]
merge-tool-edits-conflict-markers = true
# Directory diffing is barely usable in vimdiff without additional plugins
edit-args = [
    "-f", "-d", "$left", "$right", "-c", "echohl WarningMsg", "-c",
    # Or echomsg
    'echowin "Warning: using plain `vimdiff` as a diff editor is not recommended. See https://github.com/jj-vcs/jj/wiki/Vim for alternatives."',
    "-c", "echohl None",
]
diff-invocation-mode="file-by-file"
diff-args = ["-f", "-d", "$left", "$right"]

I haven't yet read your other thoughts (thank you!), but wanted to clarify this point quickly.

[ilyagr]

Don't use -u NONE. At least use -u DEFAULTS

BTW, I noticed that https://github.com/macvim-dev/macvim/wiki/Troubleshooting#ensure-that-configuration-files-vimrc-and-gvimrc-and-the-preferences-are-not-the-cause recommends -u NONE -U NONE. Perhaps it's better to use the defaults there too? (Entirely up to you)

[ychin]

I just updated it to use --clean instead.

I'm still thinking about this issue btw. Hopefully will find a way to fix the press-enter issue.

[ilyagr]

Thanks! OTOH, as far as I'm concerned, I'm not sure about this approach I was thinking of taking to deal with the fact that Vim's interface for dir-diffing is bad, but still somewhat functional, without plugins.

[ilyagr]

Also, thank you very much for all of your work on Vim's upstream diff mode! I didn't immediately recognize you as the same person over there, but now I have.

[ychin]

Thanks! OTOH, as far as I'm concerned, I'm not sure about this approach I was thinking of taking to deal with the fact that Vim's interface for dir-diffing is bad, but still somewhat functional, without plugins.

I actually don't understand why you set up said diff tool for jj then? It just seems to be adding more problems than otherwise. I wouldn't say vimdiff's default interface for dir diffing is usable per se, so it's better to just consider it to not be functional.

Also, thank you very much for all of your work on Vim's upstream diff mode! I didn't immediately recognize you as the same person over there, but now I have.

Thanks! I do want to make the diff mode better, since I felt like it's been mostly languishing in an almost-great status for a while and a couple improvements could really make it much more usable as the every day alternative to other diff tools.