neorg
neorg copied to clipboard
Filetype detection not enabled after adding use() in packer.nvim
Prerequisites
- [X] I am using the latest stable release of Neovim
- [X] I am using the latest version of the plugin
Neovim Version
NVIM v0.9.1
Neorg setup
require("neorg").setup {
load = {
["core.defaults"] = {},
["core.completion"] = {
config = {
engine = "nvim-cmp",
},
},
["core.concealer"] = {},
["core.dirman"] = {
config = {
workspaces = {
notes = "~/notes",
},
},
},
["core.integrations.telescope"] = {},
},
}
Actual behavior
Opening a Neorg file results in no filetype being set, :set ft
shows ft=
.
Expected behavior
After opening a Neorg file (extension *.norg
) I would expect ft=norg
. This should come with syntax and bindings enabled.
Steps to reproduce
Open a file, either directly through nvim index.norg
or via the internal :Neorg index
command.
Potentially conflicting plugins
No response
Other information
The complete configuration I used to get started using packer.nvim cam be seen here: https://github.com/alerque/que-vim/commit/e8d88250d3812c15d60f7a8d7417bc9504115421.
I've run :Neorg sync-parsers
and :TSUpdate
and others to no avail.
After loading a Neorg file if I manually set the filetype via :set ft=norg
then suddenly syntax is enabled and things start working.
Even before manually setting the filetype, the :Neorg
command is available, so the plugin loaded, just not the filetype detection bit.
I've tried using lazy loading by adding ft = "norg"
to the packer.nvim use {}
table, but to no avail.
Help
No
Implementation help
No response
could you show your packer use
statement?
I already linked to the full packer use
statement exactly as used here: https://github.com/alerque/que-vim/commit/e8d88250d3812c15d60f7a8d7417bc9504115421
Got the same issue after a :PackerUpdate
. Any news on this?
I'm setting the filetype manually for now -
vim.api.nvim_create_autocmd({ "BufRead", "BufNewFile" }, {
pattern = { "*.norg" },
callback = function()
vim.opt.ft = 'norg'
end,
})
Since 0.10.0
Neorg is recognized as a native filetype, therefore any issues related to this should since be gone! :)