enhancement: Take over all stdout's of neovim by default?

[glyh]

I really like this plugin, and I don't like vim's default outputline(i.e. at the bottom).
So is there a way that we can take over all stdouts?

[rcarriga]

Glad you're enjoying the plugin! I don't think this would be possible right now as that'd require overriding the echo/echom commands (possibly others) which AFAIK is not possible right now as they are implemented in C. You could ask on the NeoVim repo if it would be possible but I'd imagine there would be a tonne of complexity behind a change like that.

[teto]

:messages is really bad, there has been some attempts neovim/neovim#6374 to improve it bot nothing concrete yet. vim.notify is a way to bypass that but eventually we'll improve :messages. For now it's not possible to do what you ask.

[zeertzjq]

Possible solutions in Nvim: neovim/neovim#16396, neovim/neovim#16480.

[glyh]

neovim/neovim#16396 is merged, we may consider add some options for it later.

[rcarriga]

I don't think it can be used just yet, it seems the dependency on ext_cmdline causes some issues. I'm testing with

vim.ui_attach(
  vim.api.nvim_create_namespace("redirect messages"),
  { ext_messages = true },
  function(event, ...)
    if event == "msg_show" then
      local level = vim.log.levels.INFO
      local kind, content = ...
      if string.find(kind, "err") then
        level = vim.log.levels.ERROR
      end
      vim.notify(content, level, { title = "Message" })
    end
  end
)

[folke]

I just silently (for now) released a new plugin that does this and a lot more. See https://github.com/folke/noice.nvim

Feel free to test it out and give some feedback :)

[folke]

@rcarriga during blocking events, we sometimes need to render the messages without any delays.

When that's the case, I use a separate notify instance with stages=static, but that is not enough to make it work in realtime.

I'm currently patching NoifyService.push in https://github.com/folke/noice.nvim/blob/79f1ac9c524d14d5497065533ac9faa6ab38fe6e/lua/noice/hacks.lua#L144

• make animator process anything in the queue on NotifyService.push
• re-render the buffer -> this seems to be needed as well. Not 100% sure why. Possibly, because there's no visible buffer right before queing it in the animator?

Would be good to have this fixed within Notify itself, but I'm not sure what you think a proper fix would be?

[rcarriga]

Looks very cool, I'll have a go over the weekend!

Sorry if it's obvious but why do messages need to be rendered immediately during blocking events?

[folke]

for example when rendering the cmdline. But also in situations where a plugin echos a message and then waits for input. Or uses confirm, inputlist, ... Or when you open a file that is already opened in another instance of Neovim. Custom operator pending modes.

In all those cases, we need to render what's still in the Noice message queue and do redraw if the state after processing the messages was updated.

Lots of cases basically :)

[folke]

To clarify, just do something like:

vim.notify("Enter a character?")
vim.fn.getchar()

You won't see the message till after you entered a key. In this case, you want the initial message to be displayed instantly and prior to the blocking input.

Noice takes care of these kinds of situations automatically.

[rcarriga]

Ah thanks for explaining that makes complete sense! I think your solution is pretty much the right way to do it, I've added a forced render on creation and also the redraw.

Also cool to see the instances being used 😁

[rcarriga]

Closing this as there is too much complexity involved for this plugin and noice.nvim handles it well