Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Displaying the executed command might cause hit-Enter prompt #166

Closed
blueyed opened this issue Mar 25, 2016 · 29 comments · Fixed by #167
Closed

Displaying the executed command might cause hit-Enter prompt #166

blueyed opened this issue Mar 25, 2016 · 29 comments · Fixed by #167

Comments

@blueyed
Copy link
Contributor

blueyed commented Mar 25, 2016

The code at

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
Copy link
Owner

tpope commented Mar 25, 2016

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

@blueyed
Copy link
Contributor Author

blueyed commented Mar 25, 2016

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?! (

echo label request.command
)

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

@blueyed
Copy link
Contributor Author

blueyed commented Mar 25, 2016

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
Copy link
Contributor Author

blueyed commented Mar 25, 2016

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
Copy link
Owner

tpope commented Mar 25, 2016

What constitutes "middle", even?

@blueyed
Copy link
Contributor Author

blueyed commented Mar 25, 2016

The middle of the string..?!

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

@yevhen-m
Copy link

yevhen-m commented Nov 3, 2016

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

@yevhen-m
Copy link

Can somebody tell what the status of this issue?

@tpope
Copy link
Owner

tpope commented Feb 25, 2017

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

@blueyed
Copy link
Contributor Author

blueyed commented Feb 26, 2017

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

@simlei
Copy link

simlei commented Apr 17, 2019

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

@tpope
Copy link
Owner

tpope commented Jul 23, 2019

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

@Konfekt
Copy link

Konfekt commented Jul 23, 2019

Isn't #167 the way to go?

@tpope
Copy link
Owner

tpope commented Jul 23, 2019

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

@simlei
Copy link

simlei commented Jul 24, 2019

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 added a commit to blueyed/vim-dispatch that referenced this issue Jul 24, 2019
blueyed added a commit to blueyed/vim-dispatch that referenced this issue Jul 24, 2019
@blueyed
Copy link
Contributor Author

blueyed commented Jul 25, 2019

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

@petobens
Copy link

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)

dispatch-length

@blueyed
Copy link
Contributor Author

blueyed commented Jul 26, 2019

@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
Copy link
Owner

tpope commented Jul 26, 2019

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.

@tpope tpope reopened this Jul 26, 2019
@blueyed
Copy link
Contributor Author

blueyed commented Jul 26, 2019

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
Copy link

Konfekt commented Jul 26, 2019

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
Copy link
Owner

tpope commented Jul 26, 2019

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
Copy link
Contributor Author

blueyed commented Jul 26, 2019

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

@tpope
Copy link
Owner

tpope commented Jul 26, 2019 via email

@blueyed
Copy link
Contributor Author

blueyed commented Oct 22, 2019

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.

blueyed added a commit to blueyed/vim-dispatch that referenced this issue Oct 22, 2019
@tpope
Copy link
Owner

tpope commented Oct 22, 2019

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
Copy link

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
Copy link
Owner

tpope commented May 7, 2021

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
Copy link
Owner

tpope commented May 7, 2021

I think 250ea26 resolves this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants