aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua
Commit message (Collapse)AuthorAge
...
| * feat(lsp): lsp.completion support set deprecated (#29882)glepnir2024-07-31
| | | | | | | | | | | | Problem: CompletionItem in lsp spec mentioned the deprecated attribute Solution: when item has deprecated attribute set hl_group to DiagnosticDeprecated in complete function
| * vim-patch:49cdd62: runtime(doc): list of new/changed features in version9.txtzeertzjq2024-07-30
| | | | | | | | | | | | | | | | closes: vim/vim#13753 https://github.com/vim/vim/commit/49cdd629a39d7e40e7349e65cb177e2442871a04 Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * fix(treesitter): highlight anonymous nodes in inspect_treeRiley Bruins2024-07-29
| | | | | | | | | | | | | | | | | | | | **Problem:** With anonymous nodes toggled in the inspect tree, only named nodes will be highlighted when moving the cursor in the source code buffer. **Solution:** Retrieve the anonymous node at the cursor (when toggled on in the inspect tree) and highlight them when appropriate, for better clarity/specificity.
| * feat(treesitter): allow get_node to return anonymous nodesRiley Bruins2024-07-29
| | | | | | | | | | Adds a new field `include_anonymous` to the `get_node` options to allow anonymous nodes to be returned.
| * feat(treesitter): add node_for_range functionRiley Bruins2024-07-29
| | | | | | | | | | | | This is identical to `named_node_for_range` except that it includes anonymous nodes. This maintains consistency in the API because we already have `descendant_for_range` and `named_descendant_for_range`.
| * vim-patch:9.1.0636: filetype: ziggy files are not recognizedChristian Clason2024-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: ziggy files are not recognized Solution: detect '*.ziggy' files as ziggy filetype, detect '*.ziggy-schema' files as ziggy-schema filetype (EliSauder) References: https://ziggy-lang.io/ fixes: vim/vim#15355 closes: vim/vim#15367 https://github.com/vim/vim/commit/f4572cee35a6c224985e71116e676ab711c09af3 Co-authored-by: EliSauder <24995216+EliSauder@users.noreply.github.com>
| * vim-patch:9.1.0635: filetype: SuperHTML template files not recognizedChristian Clason2024-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: SuperHTML template files not recognized Solution: Update the filetype detection code to detect '*.shtml' either as HTML (Server Side Includes) or SuperHTML (template files) (EliSauder) related: vim/vim#15355 related: vim/vim#15367 https://github.com/vim/vim/commit/e57c9a19edc906a96ccb8821ae33fa6a8b20c3cd Co-authored-by: EliSauder <24995216+EliSauder@users.noreply.github.com>
| * vim-patch:partial:52e7cc2: runtime(doc): tweak documentation style a bit ↵zeertzjq2024-07-29
| | | | | | | | | | | | | | | | | | (#29897) closes: vim/vim#15371 https://github.com/vim/vim/commit/52e7cc26d81c61fff1b2e3b32e8b9b04347be1d3 Co-authored-by: h-east <h.east.727@gmail.com>
| * fix(lsp): revert text edit application order change (#29877)Mathias Fußenegger2024-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverts https://github.com/neovim/neovim/pull/29212 and adds a few additional test cases From the spec > All text edits ranges refer to positions in the document they are > computed on. They therefore move a document from state S1 to S2 without > describing any intermediate state. Text edits ranges must never overlap, > that means no part of the original document must be manipulated by more > than one edit. However, it is possible that multiple edits have the same > start position: multiple inserts, or any number of inserts followed by a > single remove or replace edit. If multiple inserts have the same > position, the order in the array defines the order in which the inserted > strings appear in the resulting text. The previous fix seems wrong. The important part: > If multiple inserts have the same position, the order in the array > defines the order in which the inserted strings appear in the > resulting text. Emphasis on _appear in the resulting text_ Which means that in: local edits1 = { make_edit(0, 3, 0, 3, { 'World' }), make_edit(0, 3, 0, 3, { 'Hello' }), } `World` must appear before `Hello` in the final text. That means the old logic was correct, and the fix was wrong.
| * fix(version): return nil with empty stringMaria José Solano2024-07-27
| |
| * vim-patch:9.1.0616: filetype: Make syntax highlighting off for MS Makefiles ↵zeertzjq2024-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#29874) Problem: filetype: Make syntax highlighting off for MS Makefiles Solution: Try to detect MS Makefiles and adjust syntax rules to it. (Ken Takata) Highlighting of variable expansion in Microsoft Makefile can be broken. E.g.: https://github.com/vim/vim/blob/2979cfc2627d76a9c09cad46a1647dcd4aa73f5f/src/Make_mvc.mak#L1331 Don't use backslash as escape characters if `make_microsoft` is set. Also fix that `make_no_comments` was not considered if `make_microsoft` was set. Also add description for `make_microsoft` and `make_no_comments` to the documentation and include a very simple filetype test closes: vim/vim#15341 https://github.com/vim/vim/commit/eb4b903c9b238ebcc1d14cfcb207129b4931a33d Co-authored-by: Ken Takata <kentkt@csc.jp>
| * vim-patch:9.1.0612: filetype: deno.lock file not recognizedChristian Clason2024-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: deno.lock file not recognized Solution: detect 'deno.lock' as json filetype (カワリミ人形) Reference: https://docs.deno.com/runtime/manual/basics/modules/integrity_checking/#caching-and-lock-files closes: vim/vim#15333 https://github.com/vim/vim/commit/df77c8ad3974e44df2e588de5f465072371cab69 Co-authored-by: カワリミ人形 <kawarimidoll+git@gmail.com>
| * fix(health): fix pyenv root and python exepath detect issueAbao Zhang2024-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following two issues: - pyenv root detection issue When `PYENV_ROOT` environment variable is not set, neovim will detect pyenv's root via `pyenv root` command, but which will be always fail because `vim.fn.system()` returns result with additional `\n`. Using `vim.system` instead prevents this problem. to trim it before check whether it is exists - python executable path detection issue Filter unrelated `python-config` in cases where multiple python versions are installed, e.g. `python-config`, `python3.10-config`, `python3.11-config` etc.
| * vim-patch:9.1.0610: filetype: OpenGL Shading Language files are not detected ↵Gregory Anders2024-07-23
| | | | | | | | | | | | | | | | | | | | | | | | (#29831) Problem: filetype: OpenGL Shading Language files are not detected Solution: detect various file extensions as GLSL filetype, include indent and syntax script, do no longer recognize '*.comp' as Mason filetype (Gregory Anders) closes: vim/vim#15317 https://github.com/vim/vim/commit/e4b991ed36f96dd01c6d75e46a04fd1a99180e58
| * vim-patch:9.1.0603: filetype: use correct extension for DraculaChristian Clason2024-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: pattern detection for Dracula language uses "*lvs" and "*lpe". as there is no dot, those are not treated as extensions which they should (judging by 'runtime/syntax/dracula.vim' and common sense). Solution: use "*.lvs" and "*.lpe" patterns (Evgeni Chasnovski) closes: vim/vim#15303 https://github.com/vim/vim/commit/5fb801a74faaf3ef1262c2988b8801500ca71646 Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
| * vim-patch:9.1.0602: filetype: Prolog detection can be improvedzeertzjq2024-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: Prolog detection can be improved Solution: update the prolog detection regex (igna_martinoli) related: vim/vim#10835 related: vim/vim#15206 closes: vim/vim#15253 https://github.com/vim/vim/commit/37853b7de31ef34153fe76aa2b740d517ed0e5d4 N/A patch: vim-patch:7347642: runtime(filetype): Fix Prolog file detection regex Problem: filetype: .pro file detection for Prolog is broken Solution: fixed the regex to only match on the tested cases (igna_martinoli) fixes: vim/vim#10835 closes: vim/vim#15206 https://github.com/vim/vim/commit/7347642633eb2de23a78c51a4388c9080440eec4 Co-authored-by: igna_martinoli <ignamartinoli@protonmail.com> Co-authored-by: clason <c.clason@uni-graz.at>
| * vim-patch:eb6d733: runtime(doc): fix more inconsistencies in assert function ↵zeertzjq2024-07-19
| | | | | | | | | | | | | | | | | | docs (#29796) related: https://github.com/vim/vim/pull/15280#issuecomment-2233771449 closes: vim/vim#15285 https://github.com/vim/vim/commit/eb6d733bef312a0634770e023e8a41f0347f1503
| * perf(filetype): implement parent pattern pre-matching (#29660)Evgeni Chasnovski2024-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: calling `vim.filetype.match()` has performance bottleneck in that it has to match a lot of Lua patterns against several versions of input file name. This might be the problem if users need to call it synchronously a lot of times. Solution: add "parent pattern pre-matching" which can be used to quickly reject several potential pattern matches at (usually rare) cost of adding time for one extra Lua pattern match. "Parent pattern" is a manually added/tracked grouping of filetype patterns which should have two properties: - Match at least the same set of strings as its filetype patterns. But not too much more. - Be fast to match. For them to be effective, group should consist from at least three filetype patterns. Example: for a filetpye pattern ".*/etc/a2ps/.*%.cfg", both "/etc/" and "%.cfg" are good parent patterns (prefer the one which can group more filetype patterns). After this commit, `vim.filetype.match()` on most inputs runs ~3.4 times faster (while some inputs may see less impact if they match many parent patterns).
| * vim-patch:9.1.0596: filetype: devscripts config files are not recognized ↵Christian Clason2024-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | (#29773) Problem: filetype: Debian devscripts config files are not recognized Solution: detect devscripts.conf and .devscripts files as sh filetype (sourced by /bin/sh) closes: vim/vim#15227 https://github.com/vim/vim/commit/76c19028ffc8b00816df7bc48985c92f7bacbcfb Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
| * vim-patch:c1b3984: runtime(doc): minor updates. (#29778)zeertzjq2024-07-18
| | | | | | | | | | | | | | closes: vim/vim#15280 https://github.com/vim/vim/commit/c1b3984a7b3cd6adcd1f43e558cb04fad1af3182 Co-authored-by: Shane Harper <shane@shaneharper.net>
| * fix(lsp): inlay hints are rendered in the correct order (#29707)Amit Singh2024-07-17
| | | | | | | | | | | | | | | | | | | | | | Problem: When there are multiple inlay hints present at the same position, they should be rendered in the order they are received in the response from LSP as per the LSP spec. Currently, this is not respected. Solution: Gather all hints for a given position, and then set it in a single extmark call instead of multiple set_extmark calls. This leads to fewer extmark calls and correct inlay hints being rendered.
| * fix(treesitter): recognize aliased parsers in omnifunc, query linterRiley Bruins2024-07-17
| | | | | | | | | | | | | | | | | | **Problem:** A query file for something like `html_tags` will not be given html node completion **Solution:** Check for parser aliases before offering completions Co-authored-by: Lewis Russell <me@lewisr.dev>
| * vim-patch:9.1.0593: filetype: Asymptote files are not recognizedChristian Clason2024-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: Asymptote files are not recognized Solution: detect '*.asy' files as asy filetype, include ftplugin and syntax plugin (AvidSeeker). Reference: https://asymptote.sourceforge.io/ closes: vim/vim#15252 https://github.com/vim/vim/commit/3088ef094da721dac8c0363a6c9e14eaf9313929 Co-authored-by: AvidSeeker <avidseeker7@protonmail.com>
| * vim-patch:9.1.0592: runtime: filetype: Mediawiki files are not recognizedChristian Clason2024-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: Mediawiki files are not recognized Solution: detect "*.mw" and "*.wiki" as mediawiki filetype, include basic syntax and filetype plugins. (AvidSeeker) closes: vim/vim#15266 https://github.com/vim/vim/commit/b5844104ab1259e061e023ea6259e4eb002e7170 Co-authored-by: AvidSeeker <avidseeker7@protonmail.com>
| * vim-patch:9.1.0591: filetype: *.wl files are not recognizedChristian Clason2024-07-17
| | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: *.wl files are not recognized Solution: Detect '*.wl' files as Mathematica package files (Jonas Dujava) closes: vim/vim#15269 https://github.com/vim/vim/commit/c6d7dc039342fbe1cf432c7f8e7e391063de210b Co-authored-by: Jonas Dujava <jonas.dujava@gmail.com>
| * fix(lsp): don't show codelens for buffers that don't support it (#29690)Riley Bruins2024-07-16
| |
| * fix(snippet): modify base indentation when there's actually whitespace (#29670)Maria José Solano2024-07-16
| |
| * fix(tohtml): support ranges againaltermo2024-07-16
| |
| * fix(tohtml): extmark text may be out of boundsaltermo2024-07-16
| |
| * vim-patch:df62c62: runtime(doc): grammar fixes in options.txt (#29729)zeertzjq2024-07-15
| | | | | | | | | | | | | | closes: vim/vim#15265 https://github.com/vim/vim/commit/df62c62177bd4dffce880b7a5711594865090953 Co-authored-by: Dominique Pellé <dominique.pelle@gmail.com>
| * docs(lpeg): merge upstream changesMaria José Solano2024-07-15
| |
| * docs: misc (#29622)dundargoc2024-07-15
| | | | | | | | Co-authored-by: Christian Clason <c.clason@uni-graz.at> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
| * vim-patch:9.1.0586: ocaml runtime files are outdatedChristian Clason2024-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ocaml runtime files are outdated Solution: sync those files with the upstream repo, detect a few more ocaml files (Yinzuo Jiang) closes: vim/vim#15260 https://github.com/vim/vim/commit/700cf8cfa1e926e2ba676203b3ad90c2c2083f1d Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
| * vim-patch:9.1.0583: filetype: *.pdf_tex files are not recognizedChristian Clason2024-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: *.pdf_tex files are not recognized Solution: Detect '*.pdf_tex' files as tex filetype (Jonas Dujava) Those files are generated by inkscape, when exporting, see e.g. https://inkscape.org/doc/inkscape-man.html closes: vim/vim#15250 https://github.com/vim/vim/commit/28145e005d646cb0477aa26ef69d0f651a9f9d27 Co-authored-by: Jonas Dujava <jonas.dujava@gmail.com>
| * Merge pull request #29632 from echasnovski/filetype-refactorLewis Russell2024-07-13
| |\ | | | | | | refactor(filetype): extract some functions, use more cache
| | * refactor(filetype): use Lua patterns without implicit anchoringEvgeni Chasnovski2024-07-12
| | |
| | * refactor(filetype): extract expanding env. vars in separate functionEvgeni Chasnovski2024-07-12
| | |
| | * perf(filetype): cache (more) pattern data during "add" timeEvgeni Chasnovski2024-07-12
| | |
| | * refactor(filetype): unify matching patterns with pos/neg priorityEvgeni Chasnovski2024-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: due to single list of sorted patterns, their matching inside `vim.filetype.match()` was done very similarly but with extra checks to stop processing negative priority patterns before extensions. Solution: create separated sorted lists for patterns with non-negative and negative priorities. This allows to process them in a single extracted function making the main codeflow a bit nicer and more easily expandable.
| * | vim-patch:9.1.0572: cannot specify tab page closing behaviour (#29682)zeertzjq2024-07-13
| |/ | | | | | | | | | | | | | | | | | | | | | | Problem: cannot specify tab page closing behaviour (Gianluca Pacchiella) Solution: Add the 'tabclose' option (LemonBoy). fixes: vim/vim#5967 closes: vim/vim#15204 https://github.com/vim/vim/commit/5247b0b92e191a046b034171a3b34031e317735f Co-authored-by: LemonBoy <thatlemon@gmail.com>
| * vim-patch:9.1.0568: Cannot expand paths from 'cdpath' settingzeertzjq2024-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Cannot expand paths from 'cdpath' setting (Daniel Hahler) Solution: Implement 'cdpath' completion, add the new 'dir_in_path' completion type (LemonBoy) fixes vim/vim#374 closes: vim/vim#15205 https://github.com/vim/vim/commit/a20bf69a3b32024cb7809be87af33bf9dc490a19 Co-authored-by: LemonBoy <thatlemon@gmail.com>
| * vim-patch:9.1.0555: filetype: angular ft detection is still problematicChristian Clason2024-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: angular ft detection is still problematic (after 9.1.0551) Solution: detect htmlangular filetype only by inspecting the content, do not try to determine it from a generic name like '*.component.html' For the reasons mentioned here: https://github.com/vim/vim/pull/13594#issuecomment-1834465890 related: vim/vim#15190 related: vim/vim#13594 related: vim/vim#13604 https://github.com/vim/vim/commit/c03f631b7b01e672787b222a55898f8dcac8d859 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.1.0553: filetype: *.mcmeta files are not recognizedChristian Clason2024-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: *.mcmeta files are not recognized Solution: Detect '*.mcmeta' files as json filetype (Tomodachi94) "pack.mcmeta" was added to the JSON tests because that is the most common filename with that extension. There are currently 34,000 instances of this file extension on GitHub: https://github.com/search?q=path%3A*.mcmeta&type=code&p=2 .zip files with this extension have downloads in the millions on sites like CurseForge: https://www.curseforge.com/minecraft/search?page=1&pageSize=20&sortBy=relevancy&class=texture-packs Further reading about the file extension: https://minecraft.wiki/w/Tutorials/Creating_a_resource_pack#Creating_a_.MCMETA_file closes: vim/vim#15189 https://github.com/vim/vim/commit/d33a518025765c4a3530ad6cfb6cab83a30c8f55 Co-authored-by: Tomodachi94 <tomodachi94@protonmail.com>
| * vim-patch:9.1.0551: filetype: htmlangular files are not properly detectedChristian Clason2024-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: htmlangular files are not properly detected Solution: Use the new htmlangular filetype for angular files, because since angular v17, those are no longer valid HTML files. (Dennis van den Berg) Since Angular 17, the new Control Flow Syntax is not valid HTML. This PR adds a new filetype detection for the HTML templates of Angular. It first checks the filename. The Angular convention is to use *.component.html for the template. However, this is not mandatory. If the filename does not match, it will check the contents of the file if it contains: - One of the Control-Flow blocks: @if, @for, @switch, @defer - A structural directive: *ngIf, *ngFor, *ngSwitch, *ngTemplateOutlet - Builtin Angular elements: ng-template or ng-content - String interpolation: {{ something }} This enables the Angular LSP to attach only to htmlangular filetypes, as well as language parsers, such as tree-sitter. closes: vim/vim#15190 https://github.com/vim/vim/commit/1ad194c0dfd82ca1e7a1b6f2fca89a487794158d Co-authored-by: Dennis van den Berg <dennis.vandenberg@nedap.com>
| * vim-patch:9.1.0550: filetype: antlr4 files are not recognizedChristian Clason2024-07-10
| | | | | | | | | | | | | | | | | | | | | | | | Problem: filetype: antlr4 files are not recognized Solution: Detect '*.g4' as antlr4 filetype, include a simple antlr4 syntax and filetype plugin (Yinzuo Jiang) closes: vim/vim#15191 https://github.com/vim/vim/commit/4a7a4a3675b6ad90a525524ba4684925df212325 Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
| * vim-patch:9.1.0547: No way to get the arity of a Vim function (#29638)zeertzjq2024-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: No way to get the arity of a Vim function (Austin Ziegler) Solution: Enhance get() Vim script function to return the function argument info using get(func, "arity") (LemonBoy) fixes: vim/vim#15097 closes: vim/vim#15109 https://github.com/vim/vim/commit/48b7d05a4f88c4326bd5d7a73a523f2d953b3e51 Co-authored-by: LemonBoy <thatlemon@gmail.com>
| * fix(diagnostic): fix backwards compatibility for goto_next and goto_prev ↵Max Coplan2024-07-09
| | | | | | | | (#29593)
| * fix(lua): change some vim.fn.expand() to vim.fs.normalize() (#29583)zeertzjq2024-07-09
| | | | | | Unlike vim.fn.expand(), vim.fs.normalize() doesn't expand wildcards.
| * perf(filetype): skip contents check in `match()` if there is no contents ↵Evgeni Chasnovski2024-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#29596) Problem: `vim.filetype.match()` tries to match on contents even if there is no contents (empty buffer or `{''}` explicit contents). This results in extra avoidable execution duration for cases. It matters, for example, when trying to match filetype based solely on file name (which still needs `contents` or `buf` to properly match earlier in the code path). Solution: skip matching based solely on contents if it is `{''}`. This works because: - Matching solely on content is done after any user-configured `vim.filetype.add()` hooks. - All default matching on content might depend on supplied path *only* if there is non-empty content (like in `require('vim.filetype.detect').match_from_hashbang()`).
| * vim-patch:94c1c66: runtime(tf): include tf ftplugin fileChristian Clason2024-07-08
| | | | | | | | | | | | | | | | | | | | | | Adds ftplugin support for tf (TinyFugue). Comment support taken from [here](https://github.com/kruton/tinyfugue/blob/1e8ac0bb014036c07bb3c679b0292ef20a6a0bb5/src/command.c#L568) closes: vim/vim#15168 https://github.com/vim/vim/commit/94c1c6638a652cbe21b4d25ae5f26078e2e633d7 Co-authored-by: Riley Bruins <ribru17@hotmail.com>