feat: use virtual title in notifications if title is not supported

[Akmadan23]

Having [NvimTree] as a notification header while using a notification system that actually supports title is redundant, so with this simple change it will be added only if needed.

[Akmadan23]

And maybe now it's time to raise stylua's column width, splitting these boolean expressions would be really confusing.

[alex-courtis]

It is hard to determine whether we have an alternate notify plugin installed.

Could we be clever and look for the __call metamethod on vim.notify to indicate that it is overridden?

Experimenting:

[2023-10-02 10:45:23] [dev] default vim.notify=<function 1>

[2023-10-02 10:49:32] [dev] "rcarriga/nvim-notify" vim.notify={
  _config = <function 1>,
  _print_history = <function 2>,
  async = <function 3>,
  dismiss = <function 4>,
  history = <function 5>,
  instance = <function 6>,
  notify = <function 7>,
  open = <function 8>,
  pending = <function 9>,
  setup = <function 10>,
  <metatable> = {
    __call = <function 11>
  }
}

[2023-10-02 10:55:12] [dev] "folke/noice.nvim" vim.notify=<function 1>

That's a no...

We couldn't detect whether vim.notify has changed over time either, due to plugin load/setup order.

[alex-courtis]

This will result in user happiness, thanks for taking it on.

We have options:

1. Harden detection. It might be nicer to put it in notify.setup so it runs at a controlled time rather than on module load.
2. Add notify.prefix boolean|string or similar, default "[NvimTree]\n"

I prefer 1 - we have too many options and users can add additional notify plugin detection if needed.

Edit: moving to setup is not possible.

[alex-courtis]

This one's not happy when we don't have noice:

Error detected while processing /tmp/nvt-dev/nvt-dev.lua:
E5113: Error while calling lua chunk: ...v/site/pack/packer/start/master/lua/nvim-tree/notify.lua:4: module 'noice.source.notify' not found:
        no field package.preload['noice.source.notify']
        no file './noice/source/notify.lua'
        no file '/usr/share/luajit-2.1/noice/source/notify.lua'
        no file '/usr/local/share/lua/5.1/noice/source/notify.lua'
        no file '/usr/local/share/lua/5.1/noice/source/notify/init.lua'
        no file '/usr/share/lua/5.1/noice/source/notify.lua'
        no file '/usr/share/lua/5.1/noice/source/notify/init.lua'
        no file './noice/source/notify.so'
        no file '/usr/local/lib/lua/5.1/noice/source/notify.so'
        no file '/usr/lib/lua/5.1/noice/source/notify.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file './noice.so'
        no file '/usr/local/lib/lua/5.1/noice.so'
        no file '/usr/lib/lua/5.1/noice.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        ...v/site/pack/packer/start/master/lua/nvim-tree/notify.lua:4: in main chunk
        [C]: in function 'require'
        ...-dev/site/pack/packer/start/master/lua/nvim-tree/api.lua:1: in main chunk
        [C]: in function 'require'
        /tmp/nvt-dev/nvt-dev.lua:49: in main chunk

[Akmadan23]

Right, I forgot to put parentheses on the second part, it did not show up to me because I have nvim-notify enabled.

[alex-courtis]

And maybe now it's time to raise stylua's column width, splitting these boolean expressions would be really confusing.

Yeah, this is getting silly. The intent is to keep statements minimal however sometimes you just have to have long lines for readability.

      if
        (filters.config.filter_no_buffer or renderer.config.highlight_opened_files ~= "none")
        and vim.bo[data.buf].buftype == ""
      then

How about trying, say, 140 on a new branch and we see how it looks?

[alex-courtis]

Would it be possible for us to move notify_once to notify.lua?

FYI: my nvim-tree availability is late Sat to early Mon AEST

[Akmadan23]

We have options:

1. Harden detection. It might be nicer to put it in notify.setup so it runs at a controlled time rather than on module load.

2. Add notify.prefix boolean|string or similar, default "[NvimTree]\n"

I prefer 1 - we have too many options and users can add additional notify plugin detection if needed.

Yeah, I also initially considered to add a user option to manage it, but this is such a slight and almost irrelevant improvement that probably no one would care about going out of their way to change it.

In order to harden detection, as it stands now the notification plugin must be loaded before nvim-tree, but that's something that the user should do manually, so it isn't ideal...

Otherwise we can put the boolean expression inside a function that gets evaluated each time. I'm trying to create an hybrid that evaluates the expression only once (the first time it gets called) and then reuse its result without other pointless evaluations.

[Akmadan23]

Would it be possible for us to move notify_once to notify.lua?

That would make sense, but there are a couple of choices to be made to make it consistent with other members of the notify module. Maybe we can discuss it in a future PR (unless it can be useful to achieve our goal here).

Edit: now that I think about it... Can't we just use notify.warn? The "once" part seems unnecessary since in both cases the notification will be launched once.

[Akmadan23]

How about trying, say, 140 on a new branch and we see how it looks?

140 seems reasonable, I'm not sure what you mean by seeing how it looks on a new branch however. I mean, if we want to merge this when it will be ready I don't see any other decent alternative...

[Akmadan23]

This is the most efficient and effective solution I can find

[alex-courtis]

Edit: now that I think about it... Can't we just use notify.warn? The "once" part seems unnecessary since in both cases the notification will be launched once.

Thank you. That simplifies greatly.

[alex-courtis]

• nvim-notify
• noice
• notifier

[alex-courtis]

140 seems reasonable, I'm not sure what you mean by seeing how it looks on a new branch however. I mean, if we want to merge this when it will be ready I don't see any other decent alternative...

Added a temporary suppression.

Changing format disrupts PRs in flight, so we will do that when the queue is empty.