-
Notifications
You must be signed in to change notification settings - Fork 184
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
Beta-testing 'mini.notify' #640
Comments
congratulations on the new module! my first impression is quite positive and favorable. I haven't got the a lot of time to play with it, but I wanted to kindly note some initial observations:
Error executing Lua callback: (mini.notify) Only valid values of `vim.log.levels` are supported.
stack traceback:
[C]: in function 'error'
...m/.local/share/sila/lazy/mini.notify/lua/mini/notify.lua:807: in function 'error'
...m/.local/share/sila/lazy/mini.notify/lua/mini/notify.lua:280: in function 'notify'
...share/sila/lazy/pomo.nvim/lua/pomo/notifiers/default.lua:68: in function '_update'
...share/sila/lazy/pomo.nvim/lua/pomo/notifiers/default.lua:99: in function 'start'
...ssam/.local/share/sila/lazy/pomo.nvim/lua/pomo/timer.lua:129: in function 'start'
...assam/.local/share/sila/lazy/pomo.nvim/lua/pomo/init.lua:36: in function 'start_timer'
...re/sila/lazy/pomo.nvim/lua/pomo/commands/timer_start.lua:17: in function <...re/sila/lazy/pomo.nvim/lua/pomo/commands/timer_start.lua:5> I checked the plugin source code, and actually, it should works. It was working with vanilla neovim, and worked with fidget and nvim-notify.
|
This is indeed because 'epwalsh/pomo.nvim' doesn't use
There is no error with default
'mini.notify' does not (at least at the moment) override anything except LSP progress handler. So Neovim's errors are still expected to be shown using built-in mechanism.
Well, it takes notification object as input and should return the string to be used as new message. To prepend notification level before message, you can use something like this: local format = function(notif) return string.format('%s: %s', notif.level, notif.msg) end
require('mini.notify').setup({ content = { format = format } }) |
Thank you for the response.
I wasn't aware that it should only accept an integer or nil. Now I understand why I encountered errors when I routed the By the way, I have a notification function that provides highlights and icons for protected requires in modules. Upon checking, I realized I used the same approach with strings :(. So, I made some modifications, and now whether I write 'ERROR' or 3, it will always output 3 😌. This eliminates the need to remember which number corresponds to which log level, solving the issue. Here's the function I referred to for reference:function M.custom_notify(message, level)
local levels = {
DEBUG = 1,
ERROR = 4,
INFO = 2,
OFF = 5,
TRACE = 0,
WARN = 3,
}
local highlight = {
[levels.ERROR] = "ErrorMsg",
[levels.WARN] = "WarningMsg",
[levels.INFO] = "None",
[levels.DEBUG] = "Comment",
}
local style = {
[levels.ERROR] = "✗",
[levels.WARN] = "⚠",
[levels.INFO] = "ℹ",
[levels.DEBUG] = "☰",
}
-- Check if level is a string or a number
local levelValue = type(level) == "number" and level or levels[level]
local icon = style[levelValue] or "ℹ"
local hl = highlight[levelValue] or "None"
vim.notify(icon .. ": " .. message, levelValue, { highlight = hl })
end
this is good, I didn't know that just putting |
I mean, I don't like this either, but it is the documented and declared function interface. The functions from 'mini.notify' and notification object itself use level names as strings ("ERROR", "WARN", etc.), which for me is more explicit. |
Hi @echasnovski, Thanks for the work you put into this module!
A use case could be like nvim_notify that uses this table to set the the notification's title. |
I've thought about incorporating General users of
Unfortunately, this is not really usable with 'mini.notify' because all notifications are shown in a single window (with a single title). The best it can be is a custom prefix. |
This is exactly what I had in mind, since the default implementation of |
This can be done by user when overriding local mini_notify = MiniNotify.make_notify()
vim.notify = function(msg, level, opts)
opts = opts or {}
if opts.title ~= nil then msg = string.format('[%s]: %s', opts.title, msg) end
mini_notify(msg, level)
end |
Wow, I love this! I always felt lost waiting for my LS to spin up. No more! :) I tried to configure the width of the window to be wider so lines wrap less. I find the wrapping jarring. Unfortunately, changing the width property of the window had no effect. I wonder if wrapped lines would be more readable if they were indented one or two spaces below the first line of a message. Anyway, thanks again, this makes my brain happy as-is. |
Thanks for kind words!
First prototype did include empty line between consecutive notifications. But this looked like consuming unnecessarily too much vertical space. Second prototype included prefix before each notification (with notification time and vertical separator) and deemed to be the most usable. That said, I probably should add an easily set |
Hello again, I'm encountering an issue when resize Neovim. I have an autocmd for refresh mini.notfiy when VimResize event occurs. Firstly, sometimes it doesn't work, and the window remains at its initial position. Secondly, even when it works, it doesn't respect the vim.api.nvim_create_autocmd("VimResized", {
callback = function()
mini_notify.refresh()
end,
}) f8583994-31e2-42fc-bd08-9c92af713c2c.mp4thank you edit: adding video. |
First of all, 'mini.notify' should react to Edit: This autocommand now is on
I think I know what the issue here is. Does it properly react to resize with plain If you have something like require('mini.notify').setup({
window = {
config = function()
-- Use your table here
return { col = vim.o.columns - 2, row = vim.o.lines - 2 }
end,
},
}) |
yes it does work properly with resizing.
alright, I didn't know that we should do it as a function but this is magically worked. Thank you. |
Yes, |
👋 I noticed that using mini.notify causes the intro text to disappear. Steps to reproduce:
Note that there is no intro text (occasionally I can see it briefly before it disappears). This is using Nvim v0.10.0-dev-2240+ga060c13f5. |
Thanks for reporting this! It seems to be not an issue with 'mini.notify' but a result of neovim/neovim#27266. it manifests in 'mini.notify' because it uses In the meantime I'd suggest the proper fix to root cause of the problem: use 'mini.starter' 😅 |
I've pushed an update that implements new |
I tried it just now with 'lua-language-server' which takes one-two seconds to load workspace and could not reproduce it (0 out of 5 times). Also this is a quite weird looking error message. I'll try tomorrow with 'rust-analyzer'. Any particular open-sourced repository I could try? |
I've only ever seen the issue with You can give WezTerm a try. I can reproduce the issue pretty consistently by opening It looks like notifications are being submitted very quickly. Possibly a bunch are being buffered, I quit vim (which presumably destroys the update window), and then the update code has problems because its window disappeared. Maybe. |
@jason0x43, yes I indeed could reproduce this in Neovim 0.9.5. In 0.10.0 (current Nightly) there are no errors but there is a slightly annoying lag before closing. This should be fixed on latest |
With the release of 0.12.0, 'mini.notify' is now out of beta-testing. Huge thanks to everyone for participating and giving feedback! |
Please leave your feedback about new mini.notify module here. Feel free to either add new comment or positively upvote existing one.
Some things I am interested to find out (obviously, besides bugs):
Thanks!
The text was updated successfully, but these errors were encountered: