bug: '@' character in alternative keywords
Did you check docs and existing issues?
- [X] I have read all the todo-comments.nvim docs
- [X] I have updated the plugin to the latest version before submitting this issue
- [X] I have searched the existing issues of todo-comments.nvim
- [X] I have searched the existing issues of plugins related to this issue
Neovim version (nvim -v)
NVIM v0.10.1
Operating system/version
Artix Linux OpenRC 6.11
Describe the bug
I have found no way to make todo-comments recognize keywords starting by '@', e.g., '@todo', '@note', ...
Furthermore, putting a '@' character in the alternative keywords breaks the entire plugin, making it not recognize any other label, even if there is no '@' in its alternatives. For clarity, consider '@todo' as the only alt for TODO and 'bug' the only alt for FIX. Neither '@todo' nor 'bug' are recognized anymore.
I have also tried changing the recognition pattern, by escaping and by not escaping the '@' character. In both cases, the plugin works correctly with the specified alternatives in keywords, but does not recognize the '@' character. For clarity, consider 'todo' the only alternative for TODO and consider '[[@\b(KEYWORDS)\b]]' the recognition pattern. Then, '@todo' is not recognized by the plugin.
As of now, I have not found any way to have the '@' character be recognized.
Steps To Reproduce
Add the '@' character in one of the alternatives keywords.
Expected Behavior
The '@' is considered as an alphanumerical value and comments starting with '@[KEYWORD]' are highlighted.
Repro
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
spec = {
{ "folke/todo-comments.nvim", opts = {
signs = true, -- show icons in the signs column
sign_priority = 8, -- sign priority
-- keywords recognized as todo comments
keywords = {
FIX = { icon = " ", color = "error", alt = { "@bug" }, },
TODO = { icon = " ", color = "info", alt = { "@todo" } },
NOTE = { icon = " ", color = "hint", alt = { "note" } },
WARN = { icon = " ", color = "warning", alt = { "warning" } },
HACK = { icon = " ", color = "warning" },
PERF = { icon = " ", alt = { "performance" } },
},
gui_style = {
fg = 'NONE', -- The gui style to use for the fg highlight group.
bg = 'BOLD', -- The gui style to use for the bg highlight group.
},
merge_keywords = true, -- when true, custom keywords will be merged with the defaults
-- highlighting of the line containing the todo comment
-- * before: highlights before the keyword (typically comment characters)
-- * keyword: highlights of the keyword
-- * after: highlights after the keyword (todo text)
highlight = {
multiline = true, -- enable multine todo comments
multiline_pattern = '^.', -- lua pattern to match the next multiline from the start of the matched keyword
multiline_context = 10, -- extra lines that will be re-evaluated when changing a line
before = '', -- 'fg' or 'bg' or empty
keyword = 'wide', -- 'fg', 'bg', 'wide', 'wide_bg', 'wide_fg' or empty. (wide and wide_bg is the same as bg, but will also highlight surrounding characters, wide_fg acts accordingly but with fg)
after = 'fg', -- 'fg' or 'bg' or empty
pattern = [[.*<(KEYWORDS)\s*:]], -- pattern or table of patterns, used for highlighting (vim regex)
comments_only = true, -- uses treesitter to match keywords in comments only
max_line_len = 400, -- ignore lines longer than this
exclude = {}, -- list of file types to exclude highlighting
},
-- list of named colors where we try to extract the guifg from the
-- list of highlight groups or use the hex color if hl not found as a fallback
colors = {
error = { 'DiagnosticError', 'ErrorMsg', '#DC2626' },
warning = { 'DiagnosticWarn', 'WarningMsg', '#FBBF24' },
info = { 'DiagnosticInfo', '#2563EB' },
hint = { 'DiagnosticHint', '#10B981' },
default = { 'Identifier', '#7C3AED' },
test = { 'Identifier', '#FF00FF' }
},
search = {
command = 'rg',
args = {
'--color=never',
'--no-heading',
'--with-filename',
'--line-number',
'--column',
},
-- @todo How to add @ ?
pattern = [[\b(KEYWORDS)\b]],
},
}
},
-- add any other plugins here
},
})
Duplicate of #213
My apologies for the duplicate.
As I understand, a solution has been proposed consisting of replacing the special characters with a certain string. Are there any plans to implement it or some obstacle impeding it ?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue was closed because it has been stalled for 7 days with no activity.