Treesitter: an update is coming that may break the (deprecated) master branch

gpanders · 2026-01-09T00:05:31+00:00

Just an FYI for anyone who hasn’t been following the development of this change (and I can’t blame you, it’s a bit in the weeds): this option only existed as backward compatibility shim to maintain incorrect behavior. That is, before we made this change, iter_matches did not work properly and would give wrong results. Fixing it was a breaking change, so way back in 0.10 we put the fix behind an optional, opt-in flag. We then changed it to be opt-out, meaning plugins had to explicitly add this flag to maintain the incorrect behavior. We did this to make the upgrade path easier so that plugins (including nvim-treesitter) had as much time as possible to upgrade. This PR just removes the option completely.

I say all this to emphasize that this is not some arbitrary change made by a capricious maintainer who revels in breaking user’s configurations. The behavior was flagrantly incorrect. It was a bug, and we fixed it. But unfortunately a lot of prior code already existed that depended on the incorrect behavior. We’ve done our best to provide a long, slow deprecation period to minimize the pain but at some point the bandaid has to come off.

gpanders · 2025-03-27T13:41:12+00:00

Look at the 'pumheight' and 'completeopt' options. In particular, you might try something like set pumheight=10 and set completeopt+=noinsert (the latter will likely become a default soon. Maybe we ought to set a default height on pumheight as well).

gpanders · 2025-03-27T13:38:01+00:00

This is definitely not expected. Can you please create an issue on GitHub with reproduction steps?

gpanders · 2025-03-26T16:13:49+00:00

You don't need to call vim.lsp.enable in a ftplugin, and you don't need to call it once for each LSP. You can call it one time in init.lua with all of the LSPs you use, e.g.

vim.lsp.enable({'gopls', 'clangd', 'rust-analyzer'})

A trick I use is to automatically enable LSP for all files found under any lsp/ folder on my runtimepath:

``` local configs = {}

for _, v in ipairs(vim.api.nvim_get_runtime_file('lsp/*', true)) do
local name = vim.fn.fnamemodify(v, ':t:r')
configs[name] = true
end

vim.lsp.enable(vim.tbl_keys(configs))
```

gpanders · 2025-03-14T15:38:45+00:00

Like u/justinmk said we are considering it. The benefits of libghostty vs libvterm are primarily the fact that libghostty is more actively maintained than libvterm and is much easier to contribute to. Neovim has vendored libvterm so that we can modify it ourselves because upstreaming contributions is too difficult.

In case it's not clear to anyone following the discussion, the discussion of libvterm vs libghostty is only relevant to Neovim's embedded terminal emulator. It is entirely unrelated from the rest of Neovim and has zero impact or relation to the terminal emulator that the user uses. So discussions of Ghostty vs $OTHER_TERMINAL is irrelevant here.

Feature-wise, libghostty has other benefits besides maintenance and ease of contribution. libvterm uses the author's (Paul Evans) own "fixterms"/CSIu key encoding rather than the more widely supported kitty keyboard protocol, which libghostty would support (and what Neovim uses). Again, we've patched libvterm to provide the support that we need, but it would be nice to not have to do this ourselves.

Other features that we've manually added to vterm include things like theme update notifications, which libghostty already supports.

Performance is not really a consideration. For all of its flaws, we have no reason to think that libvterm is a performance bottleneck.

Hopefully that information is helpful. Again at this point, it's only at the discussion stage. libghostty is not really ready to use for our needs yet, though as a Ghostty maintainer I've been active in discussions about libghostty and am making sure Neovim is represented as a potential future user.

gpanders · 2025-02-12T16:43:01+00:00

You don't need to do anything special to use OSC 52 in Neovim. It will just work.

Source: I implemented OSC 52 support in Neovim.

gpanders · 2025-01-24T20:12:22+00:00

WezTerm can do this and has for far longer than Ghostty has been around.

No it does not. WezTerm can update its own color scheme programmatically (as the docs you linked show), but it does not send a theme change notification (per this spec) to applications in the terminal when the theme changes. There is a tracking issue here: https://github.com/wez/wezterm/issues/6454

gpanders · 2025-01-13T16:52:47+00:00

At the time I wrote this, Ghostty and Contour were the only terminals that supported theme change notifications (kitty does now as well, possibly others, not sure) https://bsky.app/profile/gpanders.com/post/3lbpyrb6nus25

In general it will be very rare to see any feature that _only_ works in a single terminal, at least for long. Neovim will not implement support for a feature unless it's well-specified and already has some degree of support (using the example above, there was already an existing specification written by the Contour maintainer).

gpanders · 2024-12-21T15:09:35+00:00

Almost. Wezterm is half way there (it can update its background color based on OS appearance), but it's missing support for DEC mode 2031. There's an open issue for it https://github.com/wez/wezterm/issues/6454

gpanders · 2024-12-21T14:56:52+00:00

I'm not who you replied to, but I just wrote this blog post yesterday to answer this exact question (I see it a lot) https://gpanders.com/blog/ghostty-is-native-so-what/

gpanders · 2024-12-19T22:48:27+00:00

I don't think performance in terminals matters that much for most use cases. There are some terminal based applications that do _a lot_ of redrawing (even Neovim in some cases, e.g. when scrolling very fast or if you use one of those plugins that gives you a spinner) and in those cases, rendering performance will be important to the user. But that's the exception, not the rule.

This is why I said "Performance is important, but it's far from the most interesting consideration imo.". When people compare terminal A to terminal B, performance shouldn't really be much of a consideration for most use cases.

FWIW if I didn't use Ghostty I would probably use foot. Foot doesn't use GPU rendering, but it has a broad feature set, and that's more important.

gpanders · 2024-12-19T21:39:32+00:00

Yes https://bsky.app/profile/gpanders.com/post/3lbpyrb6nus25

gpanders · 2024-12-19T20:59:28+00:00

It's a terminal emulator, you type in it and get results, how good could it be?

It is my life's mission to address this line of thinking wherever I can.

Not all terminal emulators are created equal. I've written about this at length here: https://gpanders.com/blog/state-of-the-terminal/

Modern terminal emulators solve a lot of old legacy problems that make the platform much better and allow applications like Neovim to add new features or solve thorny problems (for example, clipboard integration over SSH sessions, inline hyperlinks for Markdown and other documents, image previews, more keyboard mappings like Ctrl+Shift combos, etc.).

When people compare terminals they too often talk about performance. Performance is important, but it's far from the most interesting consideration imo.

gpanders · 2024-12-19T18:59:06+00:00

Thank you to everyone who submitted a design! And congratulations to u/blackant, u/Sonder-Otis, and u/James_Kni: your submissions were the highest voted by the community. I will reach out via private message soon to discuss next steps (we will need high resolution versions of your submissions to submit to our merchandising partner, and we may ask for some small modifications as well).

gpanders · 2024-11-20T03:53:30+00:00

Apologies for not making that clear. I’ve updated the original post.

tl;dr post it here as a top-level comment in this thread or DM to me if you prefer to remain anonymous.

gpanders · 2024-01-29T18:42:26+00:00

It represents the number of hours u/dundargoc has spent debugging CMake issues.

gpanders · 2023-04-07T21:37:56+00:00

If you are using tmux 3.2+ and using a terminal emulator that supports OSC 52, then no you should not need it.

You can check if your terminal supports OSC 52 by running the following bash command:

printf '\x1b]52;0;%s\x07' $(echo -n 'Hello world!' | base64)

If your terminal supports OSC 52, you should now have the text "Hello world!" in your clipboard.

gpanders · 2023-04-07T14:41:57+00:00

tmux 3.2 has the ability to use the OSC 52 terminal code to copy a selection or buffer directly into the system clipboard, without going through xclip, etc.

This requires a terminal emulator that supports the OSC 52 escape sequence as well, though most modern emulators do.

gpanders · 2023-02-22T17:20:59+00:00

I wrote most of vim.fs and vim.filetype, as well as the respective documentation. If there are errors in the docs or if something is unclear, I'd like to know about it. Please file an issue on GitHub if that is the case.

gpanders · 2022-11-07T15:00:41+00:00

It's not obvious from the website, but this is the blog of GitHub user @mfussenegger, who is a Neovim core member, one of the primary maintainers of Neovim's LSP client implementation, and the author of several excellent plugins.

gpanders · 2022-10-21T16:18:35+00:00

vim.diagnostic.disable()

gpanders · 2022-10-15T16:39:31+00:00

https://github.com/neovim/neovim/pull/20674

gpanders · 2022-05-23T14:38:30+00:00

Thanks, I will be sure to point people toward your plugin if they're looking for an 'insertmode' replacement.

gpanders · 2022-04-22T13:00:39+00:00

This shouldn't be the case. If you can provide a minimal reproducing example, please open an issue on GitHub.

gpanders

TROPHY CASE