too many notifications

[kylo252]

Is your feature request related to a problem? Please describe. Currently, there's a notification for every "successful" action whenever removing/copying/renaming files. This makes it very noisy, especially when using rcarriga/nvim-notify

Describe the solution you'd like either convert all instances of notify.info to notify.debug, or use a global log level and make it configurable.

Describe alternatives you've considered I'm happy to submit a PR for either of those two approaches^

Additional context related: #1136, https://github.com/kyazdani42/nvim-tree.lua/pull/1333#pullrequestreview-1003446477

[otavioschwanck]

Up!

Too many notifications

[alex-courtis]

I'm happy to submit a PR for either of those two approaches^

Yes please. notify.threshold with values as per :help log_levels, default INFO.

[askfiy]

As a temporary fix:

local utils = require("nvim-tree.utils")

---@diagnostic disable-next-line: unused-local
local function notify_level(level)
    return function(msg)
        vim.schedule(function()
            vim.api.nvim_echo({ { msg, "WarningMsg" } }, false, {})
        end)
    end
end

utils.notify.warn = notify_level(vim.log.levels.WARN)
utils.notify.error = notify_level(vim.log.levels.ERROR)
utils.notify.info = notify_level(vim.log.levels.INFO)
utils.notify.debug = notify_level(vim.log.levels.DEBUG)

[kylo252]

Yes please. notify.threshold with values as per :help log_levels, default INFO.

The default level should not be INFO, otherwise it's a pointless change (notify.debug is barely used).

Neovim itself uses WARN as the default, see https://github.com/neovim/neovim/blob/e6af1cf250cb3a5e4434011333ee6de6e91a55ea/runtime/lua/vim/lsp/log.lua#L15-L16

[gegoune]

@kylo252 Are you still willing to submit PR for that?

[kylo252]

turned out trickier than anticipated since utils.notify gets called even before the setup function.

[kylo252]

I noticed a tricky problem, while testing https://github.com/nvim-tree/nvim-tree.lua/pull/1693 with regards to some keymaps:

• a: creates a file and issues an INFO-level notification (which is safe to ignore for the most part)
• c: copies a file into the clipboard, but also uses INFO-level notification, (disabling this one might make things a bit confusing, because of the lack of any feedback)

I'd say that operations such as a should instead trigger a DEBUG-level notification. This would work since DEBUG isn't used currently, so it could be set as the default to avoid a regression.

A future/ambitious(?) improvement could be to set the current state message as a variable that could then be integrated into the status-line for example, a bit inspired by g:netrw_banner I guess 😄

cc: @kyazdani42