Displaying the executed command might cause hit-Enter prompt

[blueyed]

The code at

vim-dispatch/autoload/dispatch.vim

Lines 218 to 219 in eb3e564

	echo ':!'.a:request.expanded .
	\ ' ('.handler.'/'.(!empty(pid) ? pid : '?').')'

might trigger a hit-enter prompt (when it's too long / in a small window).

This causes issues, e.g. radenling/vim-dispatch-neovim#4.
But even after fixing this, it seems like there's an issue where the tempfile from vim-dispatch-neovim only contains 10 empty lines, probably because the terminal window is still considered to be empty at that point (because of the hit-enter).

What do you think about only doing this echo if &verbose is > 0?

Is there some other way to handle this better?
As a workaround I could imagine cropping the line to something that fits into cmdheight, but that then seems to be more an issue to tackle at the core / vim.

/cc @radenling

[tpope]

I think your workaround is the way to go: Truncate a:request.expanded such that the entire line fits within &cmdheight * &columns.

[blueyed]

Given the fix for radenling/vim-dispatch-neovim#4 I could imagine that it's a similar thing, where some commands fail with "not allowed here" or something similar, and could be replaced maybe?

btw: the "Success:" message simply does not get displayed if the window is too small - instead of the hit-enter prompt?! (

vim-dispatch/autoload/dispatch.vim

Line 808 in 83e68d9

echo label request.command

)

After all, this should happen with echo in general, no?

[blueyed]

After all, this should happen with echo in general, no?

It works for displaying the cmd also when redraw is used after it.

dispatch#complete is called by dispatch-neovim in the on_exit handler, which appears to make Vim truncate the message automatically (with T in 'shortmess').
It would be nice if this mechanism could be triggered by vim-dispatch also for the case at hand.

[blueyed]

A shorter/simpler approach would be to just call :redraw after the echo (which might be changed to echom then): this would avoid the hit-enter prompt and just not display the message.

But still: it would be better to find a way to trigger Vim's auto-truncation (in the middle of the string).

[tpope]

What constitutes "middle", even?

[blueyed]

The middle of the string..?!

I agree that it's better to have control over this as with my PR.

[yevhen-m]

Hey, how can I get rid of this 'Hit ENTER' prompt?

[yevhen-m]

Can somebody tell what the status of this issue?

[tpope]

Is the -12 related to 'ruler', maybe?

[blueyed]

@tpope
Might be - or something similar. I do not have it set currently though.

[simlei]

I would very much love to see this feature implemented. Sometimes you just cannot avoid long call strings.
Best regards

[tpope]

I'm open to a "good enough" solution if someone wants to craft a PR.

[Konfekt]

Isn't #167 the way to go?

[tpope]

Needs conflict resolution but yeah, that certainly qualifies as "good enough".

[simlei]

I have that exact PR merged into my local fork which is 6 months old. It also includes fixes for another case in the same Copy&Paste DNA. Will review and post it soon.

[blueyed]

Rebased it.
Needs -13 (instead of -12) for me now.. :/

[petobens]

I've started using this but apparently cannot get (or didn't understand) the expected result. Consider the following minimal init.vim:

set nocompatible

let $DOTVIM = expand('$HOME/.config/nvim')

set runtimepath+=$DOTVIM/bundle/repos/github.com/tpope/vim-dispatch
filetype plugin indent on

Now, as in the GIF, open nvim in a small window (~60 columns) and do:

1. :e a_very_very_very_very_very_very_very_long_file_name.sh
2. :let &makeprg='sh ' . expand('%')
3. :Make!
   After 3. I see the Press ENTER... message. I thought this pr prevented this (but I might be completely missing the point)

[blueyed]

@petobens
You can test it more easily with :exe 'Dispatch! echo '.repeat('X', &columns + 100).'; sleep 2' - there should not be a hit-enter when starting the job, but there is one with the success message (which is not being truncated).

[tpope]

Oh I didn't look too closely. The success message is way more important to truncate than the start message because that one interrupts what you are doing.

[blueyed]

Ok - I've thought this should be kept verbatim, since it is available in :messages.
Should the same method used for both of them then?

[Konfekt]

Truncating the success message was what lead to resurrecting this issue; I didn't occur to me that the PR only truncates the start message.

[tpope]

I think we should probably stop using :echomsg? I think my rationale was that we should add it to messages because you might miss it, but it's not like people proactively check :messages, and the truncation thing is far more important.

[blueyed]

It could still use :echom there (with the truncated message).

[tpope]

Nah :echo is fine, truncated message would be a bit weird.

…

On Fri, Jul 26, 2019 at 16:26 Daniel Hahler ***@***.***> wrote: It could still use :echom there (with the truncated message). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#166?email_source=notifications&email_token=AAAAC6XXHYC67QJ2K7XSETLQBNMYXA5CNFSM4B7B6772YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25UEJQ#issuecomment-515588646>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAC6UMBYMYOVDSACVMADLQBNMYXANCNFSM4B7B677Q> .

[blueyed]

Looked into this now: it does not use echom, but only echo in both cases.
v:echospace can be used in newer Vim.
Do you want to keep the existing method for older Vims? (and also apply it to success messages then)

Nah :echo is fine, truncated message would be a bit weird.

Do you mean truncated messages are weird in the history, or that they should not be truncated in general?

Note that without echom they might get lost actually, due to the resizing/redrawing (when using "tmux" at least). For that it might be useful to have them available in :mess then, even if truncated.

[tpope]

I mean truncated messages are weird in history. When Vim does it, it puts the full message in history, even if it displays a truncation, but I don't think there's any way we can do the same.

The purpose of the message is to alert you when the job is done. Its historical value is extremely low, so I say switch from echomsg to echo.

[mvanderkamp]

Just popping in to say I find echomsg very useful to confirm whether a command succeeded! Would an option to use echomsg be acceptable? Happy to work on a PR, but would like to hear whether it would have a chance of merging first.

[tpope]

Building from my "truncated messages are weird in history" premise, I'm not going to add a "put a weird message in my history" option. Find a way to fix that problem and we can talk, or even better, please investigate putting into the quickfix title, after the (tmux/12345) indicator, as that seems like the perfect place for it.

[tpope]

I think 250ea26 resolves this.