-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
implement :echomsg! #1802
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
implement :echomsg! #1802
Conversation
Why not simply use the screen verification facility for testing this? Here's an example |
for (;; ) | ||
if (delete_first_msg() == FAIL) | ||
break; | ||
while(msg_delete_first()) {;} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I've seen this is the first instance of the {;}
pattern, I though we were using just {}
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will fix
@justinmk I see that you're including some changes to message.h in this PR, perhaps you could pull https://github.com/Pyrohh/neovim/commit/374d8200bfc2690232917228590862371f5dff13 in as well? I can just submit a PR if it's too far reaching. |
end) | ||
|
||
|
||
local function echomsg_bang_tests(cmd_under_test) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests for new behavior of :echomsg!
(:echomsg
with !
bang). This test group is executed twice for shortmess-=T
and shortmess+=T
.
ad1bfd9
to
38616c8
Compare
@tarruda After rebasing, I have an unexpected test failure in this PR:
If I change the expected
The test is testing the new |
@justinmk I tested this branch, and it seems you are experiencing a race condition. This patch should fix it: diff --git a/test/functional/ex_cmds/echomsg_spec.lua b/test/functional/ex_cmds/echomsg_spec.lua
index 0cea285..cf05cba 100644
--- a/test/functional/ex_cmds/echomsg_spec.lua
+++ b/test/functional/ex_cmds/echomsg_spec.lua
@@ -523,6 +523,7 @@ describe('echomsg', function()
_h.nvim('set_option', 'cmdheight', 2)
execute('nnoremap <silent> foo :silent '..cmd_under_test..' "'..fullmsg..'"<cr>')
_h.feed('foo')
+ _h.wait()
screen:expect([[
^ |
~
|
@tarruda Thanks for looking into that. I was being paranoid so I didn't want to just add a |
This is to ensure ctrl+c is only pressed after the command has started executing in the viml_system_spec.lua system() interrupt test.
Any progress in this? #2769 would benefit a lot from this, for example. |
@fmoralesc I'm thinking the OS X builds are higher priority, but then this was my next priority. The CI failures are out of control... |
Indeed! Carry on... I was just reminded of this when reviewing #2769, the messages there should probably use something like |
Closing in favor of #27855 |
Followup of my comments here: #1524 (comment) , #1524 (comment) , #1524 (comment)
Closes #2063
Closes #5103
ref #2308 #1755 #1029
ref #7291
ref #7290
ref #7326
This PR implements "bang" variants of
:echomsg
and(edit: not going to implement:echoerr
:echoerr!
; the semantics of:echoerr
differ greatly from:echomsg
, and have implications for try/catch--it wouldn't make sense for :echoerr to be "passive"). Documented as follows:Besides solving a general usability issue (avoiding the "Press ENTER" prompt for non-critical messages), this enables us to be much more consistent and less hesitant about informing the user of possibly-useful context-sensitive discoveries while bootstrapping official plugins, providers (python, clipboard), and general sanity checks (VIMRUNTIME).
Before writing tests, I would like feedback on the general approach. I usually advocate against extending vimscript, but after much thought I could not find a reasonable medium-term solution. Some ideas that I rejected:
histadd()
to allow adding to the:messages
history.histdel()
or introduce a glaring incongruity.:messages
list as a read-writev:messages
List.:messages
is a bad idea.'shortmess'
:echomsg!
and:echoerr!
. But it does not solve the use cases mentioned above (providers, sanity checks).:echomsg!
spec:silent[!]
and<silent>
set shortmess-=T
v:statusmsg
is set only by:echom[!]
v:errmsg
is set only by:echoerr
:echo
cmdheight=2
but there is a 1-line message displayed,:echom!
should not clear the existing message unless it needs more than 1 line."+N :messages" spec