-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
:messages pane #5189
base: master
Are you sure you want to change the base?
:messages pane #5189
Conversation
See also #1802 which implements |
The approach that I assumed we would take would be to expose Or--perhaps better--expose each message as an API event. Then even collection of the messages is implemented outside of the C core. In general, we want to move away from implementing features in C if possible. However, just IMO. Anything with good test coverage and no major objections by others, usually is worth including... The demo is sweet though. 🔥 It looks like this PR might be a way to close #1029. |
e4eb5b6
to
9acc548
Compare
Updated demo: https://share.esdf.io/ez62CPcIWI/messages.html |
I'm still working on the tests, but I think this is ready for comments. |
a7410fc
to
7f7a3ae
Compare
/e\|a | | ||
]]) | ||
|
||
end) |
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.
Reminder: Need to add tests for msgpane()
and msgpane_open()
General question: Shouldn't it be "window" instead of "pane"? This is not tmux after all. :-P |
src/nvim/eval.c
Outdated
if (argvars[1].v_type != VAR_UNKNOWN) { | ||
char_u *attrName = get_tv_string(&argvars[1]); | ||
int hl_id = syn_name2id(attrName); | ||
attr = syn_id2attr(hl_id); |
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.
ASAN finds a problem with :echo msgpane("asdf", 0,0)
. Parameter values not checked?
==4831==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d00023a3b8 at pc 0x0000016d5ac9 bp 0x7ffc8214cf40 sp 0x7ffc8214cf38
READ of size 4 at 0x62d00023a3b8 thread T0
#0 0x16d5ac8 in syn_id2attr /home/oni-link/git/neovim/src/nvim/syntax.c:7235:15
#1 0x89857c in f_msgpane /home/oni-link/git/neovim/src/nvim/eval.c:13071:12
#2 0x794e63 in call_func /home/oni-link/git/neovim/src/nvim/eval.c:7310:11
#3 0x7a8da4 in get_func_tv /home/oni-link/git/neovim/src/nvim/eval.c:7159:11
#4 0x839119 in eval7 /home/oni-link/git/neovim/src/nvim/eval.c:4277:15
#5 0x834c45 in eval6 /home/oni-link/git/neovim/src/nvim/eval.c:3998:7
#6 0x8318d9 in eval5 /home/oni-link/git/neovim/src/nvim/eval.c:3850:7
#7 0x82ce51 in eval4 /home/oni-link/git/neovim/src/nvim/eval.c:3602:7
#8 0x82c3e3 in eval3 /home/oni-link/git/neovim/src/nvim/eval.c:3524:7
#9 0x82b973 in eval2 /home/oni-link/git/neovim/src/nvim/eval.c:3461:7
#10 0x78d952 in eval1 /home/oni-link/git/neovim/src/nvim/eval.c:3394:7
#11 0x7eb20e in ex_echo /home/oni-link/git/neovim/src/nvim/eval.c:19415:9
#12 0xa990d0 in do_one_cmd /home/oni-link/git/neovim/src/nvim/ex_docmd.c:2193:5
#13 0xa77c17 in do_cmdline /home/oni-link/git/neovim/src/nvim/ex_docmd.c:601:20
#14 0x100c1fb in nv_colon /home/oni-link/git/neovim/src/nvim/normal.c:4489:18
#15 0xff3743 in normal_execute /home/oni-link/git/neovim/src/nvim/normal.c:1144:3
#16 0x1684d10 in state_enter /home/oni-link/git/neovim/src/nvim/state.c:56:26
#17 0xfa7ab0 in normal_enter /home/oni-link/git/neovim/src/nvim/normal.c:464:3
#18 0xd606c2 in main /home/oni-link/git/neovim/src/nvim/main.c:544:3
#19 0x7f7cc90235af in __libc_start_main (/lib64/libc.so.6+0x205af)
#20 0x445628 in _start (/home/oni-link/git/neovim/build/bin/nvim+0x445628)
0x62d00023a3b8 is located 72 bytes to the left of 34056-byte region [0x62d00023a400,0x62d000242908)
allocated by thread T0 here:
#0 0x4f8fb8 in realloc /home/oni-link/git/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:77
#1 0xe8385c in xrealloc /home/oni-link/git/neovim/src/nvim/memory.c:141:15
#2 0xc84e33 in ga_grow /home/oni-link/git/neovim/src/nvim/garray.c:96:14
#3 0x16c55ef in highlight_changed /home/oni-link/git/neovim/src/nvim/syntax.c:7376:3
#4 0x1321b77 in update_screen /home/oni-link/git/neovim/src/nvim/screen.c:342:5
#5 0x1069995 in normal_redraw /home/oni-link/git/neovim/src/nvim/normal.c:1263:5
#6 0x106702c in normal_check /home/oni-link/git/neovim/src/nvim/normal.c:1346:5
#7 0x1684723 in state_enter /home/oni-link/git/neovim/src/nvim/state.c:20:35
#8 0xfa7ab0 in normal_enter /home/oni-link/git/neovim/src/nvim/normal.c:464:3
#9 0xd606c2 in main /home/oni-link/git/neovim/src/nvim/main.c:544:3
#10 0x7f7cc90235af in __libc_start_main (/lib64/libc.so.6+0x205af)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/oni-link/git/neovim/src/nvim/syntax.c:7235:15 in syn_id2attr
Perhaps the feature should be called"message buffer". It is a buffer, right? Does it appear in the buffer list (I would say yes)? Messages normally shows in "the pager". |
runtime/doc/eval.txt
Outdated
@@ -5138,6 +5138,22 @@ msgpackparse({list}) {Nvim} *msgpackparse()* | |||
representing extension type. Second is | |||
|readfile()|-style list of strings. | |||
|
|||
msgpane({message}[, {highlight}[, {open}]]) {Nvim} *msgpane()* |
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.
So is this a completely separate mechanism from :messages
? I thought the msgpane would collect all :echomsg
messages.
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.
If msgpane collects echomsg, why is this function needed?
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.
I was thinking from the perspective of debug logging for plugin development. I thought it would be nice if a message could get into the buffer without overwriting what's displayed in the command line. I also wanted a way to make sure an important message wouldn't go unnoticed.
Let the messages buffer be a normal buffer. If user deletes it, we can deal with it (recreate it, or fallback to the pager). |
The answer to "why pane not buffer" is actually petty: |
Just "history buffer" would be confusing anyway, since there are many types of histories: message history, cmdline history, search history, ... It just feels like "pane" would introduce a completely new word to the Vim vocabulary for no good reason. On the other hand, I can't come up with a better suggestion right now.. |
Maybe |
How is the quickfix buffer implemented? is it a "normal" nofile buffer with some mappings set up? |
Popup menu was causing the current window to update with the message buffer's changes when it wasn't on screen.
4f6ea8a
to
fceea9c
Compare
I think the feature should be implemented as plugin. |
This adds the
'messagepane'
(bool) option that causes:messages
to display messages in a buffer. Only messages that are kept in history are displayed in the pane. The default message history has a limit of 200 entries, but the message pane keeps 1000 entries separately.My motivation for doing this is keeping errors and spammy messages from interrupting me as I work. I think this will be particularly useful for plugin development where the messages are intentionally verbose.
Todo:
'wrap'
.msgbuf
,message buffer
Future Todo: