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

:messages pane #5189

Open
wants to merge 40 commits into
base: master
Choose a base branch
from
Open

:messages pane #5189

wants to merge 40 commits into from

Conversation

tweekmonster
Copy link
Contributor

@tweekmonster tweekmonster commented Aug 8, 2016

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:

  • ftplugin for the message pane that provides niceties, like jumping to an error source under the cursor.
  • Better implementation of "scroll to bottom" that can handle 'wrap'.
  • Ignore errors from trying to modify the message pane buffer.
  • Vim script function for adding messages directly to the message pane.
  • Time stamped separator. Could be used for simple profiling or separating groups of messages.
  • Tests
  • Rename to msgbuf, message buffer

Future Todo:

  • Customizable history length.
  • Specify message types to display in the pane (errors or echomsg).

@tweekmonster
Copy link
Contributor Author

@justinmk
Copy link
Member

justinmk commented Aug 8, 2016

See also #1802 which implements :echomsg! (notice the "bang") to add a message to the history and "maybe" printing it (but never triggering "Press Enter" prompt).

@justinmk
Copy link
Member

justinmk commented Aug 8, 2016

The approach that I assumed we would take would be to expose :messages as a list or something like that, so that functionality like this could be done in a plugin.

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.

@tweekmonster
Copy link
Contributor Author

@justinmk Wish I saw #1802 sooner because it makes messages.c a little bit more understandable.

I tried to go the plugin route originally but the main thing I was missing was the colors. I also felt that something like this would need to be as close as possible to the bare metal to keep it snappy.

@tweekmonster
Copy link
Contributor Author

@tweekmonster tweekmonster changed the title [WIP] :messages pane [RFC] :messages pane Aug 12, 2016
@tweekmonster
Copy link
Contributor Author

I'm still working on the tests, but I think this is ready for comments.

/e\|a |
]])

end)
Copy link
Contributor Author

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()

@mhinz
Copy link
Member

mhinz commented Aug 14, 2016

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

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

@justinmk
Copy link
Member

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

@@ -5138,6 +5138,22 @@ msgpackparse({list}) {Nvim} *msgpackparse()*
representing extension type. Second is
|readfile()|-style list of strings.

msgpane({message}[, {highlight}[, {open}]]) {Nvim} *msgpane()*
Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

@justinmk
Copy link
Member

Let the messages buffer be a normal buffer. If user deletes it, we can deal with it (recreate it, or fallback to the pager).

@tweekmonster
Copy link
Contributor Author

The answer to "why pane not buffer" is actually petty: msgbuf is a variable that's already used in a couple of places. TBH, I don't like "message buffer", but "history buffer" didn't sound right either.

@mhinz
Copy link
Member

mhinz commented Aug 14, 2016

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

@tweekmonster
Copy link
Contributor Author

Maybe message window and msgwin?

@bfredl
Copy link
Member

bfredl commented Aug 14, 2016

How is the quickfix buffer implemented? is it a "normal" nofile buffer with some mappings set up?

@justinmk justinmk removed the RFC label Jan 28, 2020
SILIZ4 added a commit to SILIZ4/neovim that referenced this pull request Feb 28, 2021
@teto teto added this to the 0.6 milestone Mar 26, 2021
@bfredl bfredl modified the milestones: 0.6, backlog Oct 30, 2021
@Shougo Shougo mentioned this pull request Nov 17, 2021
@Shougo
Copy link
Contributor

Shougo commented Nov 17, 2021

I think the feature should be implemented as plugin.

@Shougo Shougo mentioned this pull request Dec 1, 2021
@dundargoc dundargoc changed the title [RFC] :messages pane :messages pane Apr 2, 2023
@zeertzjq zeertzjq added the messages UI messages, log messages label Jun 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
messages UI messages, log messages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants