summaryrefslogtreecommitdiffstatshomepage
path: root/runtime/ftplugin/lua.lua
AgeCommit message (Collapse)AuthorFiles
2025-07-16revert: "fix(runtime): set 'foldmethod' for Lua ftplugin #34929" (#34947)Phạm Bình An1
This reverts commit 12276832ab67b16f795d78c72386ab28c6ee26c7.
2025-07-14fix(runtime): set 'foldmethod' for Lua ftplugin #34929Phạm Bình An1
Problem: Neovim's Lua ftplugin doesn't set `'foldmethod'`, though Vim one sets it https://github.com/vim/vim/blob/1341176e7b800238b30a137c1ea1a31ca2c3d488/runtime/ftplugin/lua.vim#L66-L68 Solution: Set it
2025-03-18fix(runtime): E15: Invalid expression in lua file when `gf`phanium1
Problem: after https://github.com/neovim/neovim/pull/32719, `gf` error in lua: ``` E15: Invalid expression: "v:lua.require"vim._ftplugin.lua".includeexpr()" E447: Can't find file "vim._ftplugin.lua" in path ``` Solution: * use single quote (no idea why there's two pair double quote in expression). * add missing `v:fname`.
2025-03-17feat(runtime): Lua ftplugin 'includeexpr' #32719Phạm Bình An1
Problem: Current `'includeexpr'` in runtime/ftplugin/lua.vim doesn't work with Nvim Lua. Solution: Provide an improved 'includeexpr' for Lua in "ftplugin/lua.lua". Closes: https://github.com/neovim/neovim/issues/32490
2025-03-15feat(runtime): Lua ftplugin sets 'omnifunc', 'foldexpr' #32697Phạm Bình An1
Problem: - Many other ftplugin have defined 'omnifunc', but the Lua one doesn't define one, even though there is `vim.lua_omnifunc()` - Users may want "stupid" completion to fix Lua config with `nvim --clean` in case they breaks it - Nvim doesn't port Lua foldexpr from Vim Solution: - Set 'omnifunc' to 'v:lua.vim.lua_omnifunc' in ftplugin/lua.lua - Set 'foldexpr' to use treesitter
2025-02-23revert "feat(ftplugin): set 'omnifunc' of Lua to 'v:lua.vim.lua_omnifunc'" ↵Justin M. Keyes1
#32597 This reverts commit f398e3a61abbf802b49867d2f533be1b0725c0d7.
2025-02-23feat(ftplugin): set Lua 'omnifunc' to vim.lua_omnifunc #32491Phạm Bình An1
Problem: - Many other ftplugin have defined 'omnifunc', but the Lua one doesn't define one, even though there is `vim.lua_omnifunc()` - Users may want "stupid" completion to fix Lua config with `nvim --clean` in case they breaks it Solution: Set 'omnifunc' to 'v:lua.vim.lua_omnifunc' in ftplugin/lua.lua
2024-09-23fix(runtime): treat b:undo_ftplugin consistently in Lua ftplugins (#30473)zeertzjq1
- Don't assume b:undo_ftplugin is set when first modifying it. - Don't assume b:undo_ftplugin already contains some resetting.
2024-07-03fix(runtime): stop treesitter highlight in b:undo_ftplugin (#29533)zeertzjq1
It seems that nvim-treesitter stops treesitter highlight when changing filetype, so it makes sense for builtin ftplugins to do this as well. Use :call and v:lua here to allow separation with '|'.
2024-01-01feat(treesitter): highlight Lua files by default (#26824)Christian Clason1
2023-02-15feat(treesitter)!: remove g:ts_highlight_lua (#22257)Christian Clason1
This variable was only meant for easy testing during the development cycle for treesitter highlighting while Lua was the only parser useable for daily driving. Now that we have a good vimdoc parser, this approach simply doesn't scale and should be removed sooner rather than later. Instead of setting this variable, people for now should add the autocommand directly to their config: ```lua vim.api.nvim_create_autocmd('FileType', { pattern = 'lua', -- or { 'lua', 'help' } callback = function() vim.treesitter.start() end, }) ``` (or put `vim.treesitter.start()` in an `ftplugin`).
2022-09-06feat(treesitter): add vim.treesitter.start(), enable for LuaChristian Clason1
* Add vim.treesitter.start() for starting treesitter highlighting via ftplugin or autocommand (can be extended later for fold, indent, matchpairs, ...) * Add vim.treesitter.stop() for manually stopping treesitter highlighting * Enable treesitter highlighting for Lua if `vim.g.ts_highlight_lua = true` is set in `init.lua`