Skip to content

Conversation

justinmk
Copy link
Member

@justinmk justinmk commented Jan 12, 2015

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 :echoerr (edit: not going to implement :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:

+                                                     *:echom!* *:echomsg!* 
+           |:echomsg|  followed by [!] creates a
+           "transient" message, which will never cause a screen
+           scroll or a |press-enter| prompt, and is _always_
+           added to the |:messages| history (even if |:silent| or
+           |:map-<silent>| are used). This is useful for leaving
+           passive diagnostic messages without disturbing
+           usability.

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:

  • extend histadd() to allow adding to the :messages history.
    • This is icky becaus then we have to also implement histdel() or introduce a glaring incongruity.
  • expose :messages list as a read-write v:messages List.
    • Same problem as above: giving plugins the ability to delete from :messages is a bad idea.
  • create an API-only function for adding to history
    • This is fine, but I suspect that users will really appreciate being able to easily avoid the "Press ENTER" prompt.
  • add a new flag to 'shortmess'
    • This is still an option that I think is worth exploring, in addition to providing :echomsg! and :echoerr!. But it does not solve the use cases mentioned above (providers, sanity checks).

:echomsg! spec

  • writes to history even with :silent[!] and <silent>
  • no duplicates in history
  • long message(s) emmitted from a keymap-triggered script are truncated
    • if 'cmdheight' is N, message fills up to N lines, but no more.
  • echom! emmitted from command line :call Foo() invocation are truncated?
  • :echom! at user-entered command line should act the same as if from a script
  • test regressions: :exe, :echom, :echoerr, :echo, :echohl, printf()
  • behavior with laststatus=0
  • test with ":set noshowcmd"
  • test with set shortmess-=T
  • v:statusmsg is set only by :echom[!]
  • v:errmsg is set only by :echoerr
  • CTRL-G should overwrite like :echo
  • If 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

  • test overflow (very large number of notifications)
  • displays count after event loop
  • count resets after next user action
  • showcmd blanks out notification area
  • appears after all messages posted (until next user command)
  • appears only if 2 or more non-duplicate messages since last batch
  • appears in correct location

@marvim marvim added the WIP label Jan 12, 2015
@tarruda
Copy link
Member

tarruda commented Jan 12, 2015

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:

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()) {;}
Copy link
Contributor

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 {}.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix

@ghost
Copy link

ghost commented Jan 29, 2015

@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.

@justinmk justinmk changed the title [WIP] implement :echomsg!, :echoerr! [WIP] implement :echomsg! Feb 15, 2015
end)


local function echomsg_bang_tests(cmd_under_test)
Copy link
Member Author

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.

@justinmk justinmk force-pushed the echom_bang branch 2 times, most recently from ad1bfd9 to 38616c8 Compare February 18, 2015 05:08
@justinmk
Copy link
Member Author

@tarruda After rebasing, I have an unexpected test failure in this PR:

row 1:
  expected: "^                                                    "
  actual:   "                                                     "

If I change the expected ^ in row 1 to a <space>, then the result is reversed:

row 1:
  expected: "                                                     "
  actual:   "^                                                    "

The test is testing the new :echomsg! behavior, so it must be something with how my changes interact with the TUI changes.

@tarruda
Copy link
Member

tarruda commented Feb 18, 2015

@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([[
       ^                                                    |
       ~

wait() It is simply a way of saying: "Wait until all keys I've sent are fully processed". This is required because the _h.nvim('set_option', 'cmdheight', 2) may set the screen to the state you expect it to be later, and the first redraw notification will succeed, only to be followed by another that fails(sent while foo is being processed)

@justinmk
Copy link
Member Author

@tarruda Thanks for looking into that. I was being paranoid so I didn't want to just add a wait() to make it go away, but now that you explain it I suppose there is no reason to expect any particular sequence of redraws until all keys are processed.

tarruda referenced this pull request in tarruda/neovim Feb 21, 2015
This is to ensure ctrl+c is only pressed after the command has started executing
in the viml_system_spec.lua system() interrupt test.
@fmoralesc
Copy link
Contributor

Any progress in this? #2769 would benefit a lot from this, for example.

@justinmk
Copy link
Member Author

@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...

@fmoralesc
Copy link
Contributor

Indeed! Carry on... I was just reminded of this when reviewing #2769, the messages there should probably use something like silent echomsg!.

@justinmk justinmk modified the milestones: 0.3, 0.2 Jan 9, 2017
@neovim neovim deleted a comment from wsdjeg Sep 19, 2017
@bfredl bfredl modified the milestones: 0.6, backlog Oct 30, 2021
@dundargoc dundargoc removed the WIP label Feb 7, 2023
@dundargoc dundargoc changed the title [WIP] implement :echomsg! implement :echomsg! Apr 2, 2023
@neovim neovim deleted a comment from tarruda Jan 5, 2025
@neovim neovim deleted a comment from Shougo Jan 5, 2025
@justinmk
Copy link
Member Author

justinmk commented May 3, 2025

Closing in favor of #27855

@justinmk justinmk closed this May 3, 2025
@justinmk justinmk deleted the echom_bang branch May 3, 2025 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ux user experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add ability to hide warnings syntax on causes python failure when trying to edit .vimrc/.nvimrc
8 participants