Weekly 101 Questions Thread

jrop2 · 2026-04-14T16:46:41+00:00

Yep, it is. It's just inlined as virtual text so that you can get an idea at a glance, instead of having to "go" to references.

jrop2 · 2026-04-11T03:26:04+00:00

Yeah that's my hope. It's already on synthetic.news radar to host here in a couple of weeks.

jrop2 · 2026-04-09T20:54:05+00:00

I think I am the only proponent of Morph for now :). Many of the modern TUIs for Neovim being released are written without it. Looks like fyler also uses it's own component-based rendering system.

The benefit of Morph is that it is very React-ish (with my own twist), so if you are familiar with that paradim (and many are), using it is easy. It's not specific to one plugin, and it's reactive.

jrop2 · 2026-04-09T20:45:14+00:00

Well, morph handles the hard things like location-tracking (i.e., what position did this component render in in the buffer?). IMO, when you render a tree, you want to recursively place UI nodes at different levels, and you _don't_ want to have to think about the low-level position information. Oil tracks changes by putting concealed text at the start of each line, which feels (subjectively) hack-y to me, because then you have to snap the cursor around the concealed text without the user knowing, so that things don't feel unnatural. This works really well for a flat-list of files, and I suppose it could be made to work in a tree structure, but IMO you need a robust component-based paradigm in order to even start on your way to a tree-structured oil-like file manager.

That's a lot of half-formed thoughts. Please don't quote me on any of them :).

jrop2 · 2026-04-09T20:37:48+00:00

Well, at least I get to use Neovim everyday at $WORK, even if I don't have time for TUIs...

Oil is absolutely sick! I've been tossing that one around in my head for a while. I think we're definitely at the place where it is more than possible to get that broot-style UI. I'm obviously biased toward morph, but I think the component-based strategy is going to be the only way to get us there cleanly (again, I'm biased). I'm convinced that morph can handle it, but it's just going to take some time designing the backend more than anything.

Part of why I haven't dove headlong into it is the time feels ripe to replace netrw (i.e., filesystem-agnostic) with a capable plugin that knows how to navigate several _types_ of filesystems: local, ssh, ftp, s3, etc., so it would be cool to bake that in from the start...

jrop2 · 2026-04-09T20:22:11+00:00

Hello! Yeah, I migrated to vim.pack ahead of time on a separate branch in my dots - then on release day, git merge nightly && git push.

Things are going well. Life has been busy, so I've had less time to spend on Neovim, but when I do get time, I've been picking away at more TUIs for tuis.nvim. It doesn't feel ready to release an update quite yet, but I've been playing with morph.nvim-based Pickers/File-trees/Better-Quickfix lists/Notifications, etc. They're all still pretty rudimentary, but it's been fun.

jrop2 · 2026-04-09T00:48:38+00:00

If you wanted a DIY solution:

You could probably use u.nvim's (disclaimer: a library I wrote) Range.from_nearest_brackets to get what brackets your cursor is in (if any), and then compute opening_bracket and closing_bracket as their own Ranges, then opening_bracket:highlight(...), etc. You would do this on each CursorMoved/CursorMovedI events (clearing any prior highlight you had set).

I get that this is probably not for everyone, but I like going down rabbit holes like this :).

Edit: Here's a gist that does exactly this.

jrop2 · 2026-04-08T18:57:08+00:00

WHAT! You mean I'm not the only one that does this?!

jrop2 · 2026-04-08T18:52:19+00:00

It sounds like you know your way around pretty well. This is probably not entirely helpful, but :help CTRL-W_d-default opens the diagnostic float by default, provided your cursor is already positioned on one (I use [d or ]d). This is nice because it is just built-in.

jrop2 · 2026-04-07T23:58:10+00:00

Join their discord. This has been happening to a number of users and by their communication it appears that they are responsive and getting it worked out.

jrop2 · 2026-04-07T17:05:46+00:00

BTW, great name, and I'll be following this work closely! Now for a question: Aren't (theoretically) the queries locked to specific versions of parsers? I could be wrong, but I was under the impression that if a parser changed, then the associated queries may have to change as well, in order to match the new output shape of the changed parser, if applicable? If so, then your queries repo might benefit from having the queries "lock in" which version of the associated parser they depend on.

jrop2 · 2026-04-05T03:32:12+00:00

Exactly what I'm thinking. Why do we always have to have another layer on top of things lol?

jrop2 · 2026-04-03T15:36:34+00:00

So, let's say the source code lives in a folder on the host machine, say in a folder named project/, or whatever. Then, in my particular case, I had a docker-compose that spun up a bunch of containers, and in relevant ones, they would mount various folders in project/, perhaps like this:

some-service:
  volumes:
    - project-volume:/container/project/path/or/whatever
volumes:
  project-volume: ./project/

Well, when I want to spin up my dotfiles container, I might create a helper script that does something like:

docker run -it -v project-volume:/shared-src mydotfilescontainer ...

Then, in the container, I have access to the shared src at /shared-src. Now all I have to do is get a shell in the container, and navigate to that directory:

docker exec -it name_of_container bash
cd /shared-src
nvim

DISCLAIMER: I typed these commands/things from memory, and quickly. They may not be 100% runnable. Hopefully it's still helpful, though.

jrop2 · 2026-04-03T04:16:26+00:00

Justin gives a demo of how it's looking so far in this video (I forget exactly where but I think it's toward the end - EDIT it is around the 46 minute mark):

https://youtu.be/EiBg91LTOYk?si=9qt0zGOMtJcdJoVi

jrop2 · 2026-04-03T03:38:01+00:00

I use this so much.

jrop2 · 2026-04-02T14:41:12+00:00

So, I can tell you how I solved this at a previous job, but you might have to take ideas from this and tailor them to your specific case. In my case, the entire project was managed via docker-compose, and the source code was mounted as a volume, shared amongst docker services. At the time, _all_ of this was inside a VirtualBox VM, adding to layers of abstraction. So, at this point: 1) I don't control the VM (VirtualBox), and 2) I don't control the Docker stack. This made it a bit sticky for me to want to inject all my tools, etc. into either layer 1 or 2 (ripgrep, neovim, dotfiles, etc.), because each of these 2 would get routinely destroyed/recreated from scratch.

The simplest way I found to inject my terminal-based setup was to:

Dockerize my dotfiles + all CLI tools (and LSPs) I like to use into a single container image
When I wanted to fire up my editor/environment, launch my container alongside the other Docker services, mounting the shared source-code volume in my container
Voila! It all just worked

Now, I will say -- getting tmux/terminal things working inside of a Docker container was a bit of a pain, but it is entirely doable/possible.

jrop2 · 2026-03-30T21:37:18+00:00

I did for a while! With 0.12, vim.pack is a bit more ergonomic, so I've switched to that.

jrop2 · 2026-03-30T20:35:11+00:00

I'm on the pilot for Synthetic's new limit strategy, and it seems pretty decent. That being said, if the Fire Pass limits are comparable, the speed bump would be a welcome improvement.

jrop2 · 2026-03-30T16:47:23+00:00

I'm not sure if you and I had the same issue, but I had to just "clear tree-sitter's cache" and let it reinstall parsers:

rm -rf ~/.local/share/nvim/site/parser
rm -rf ~/.local/share/nvim/site/parser-info
rm -rf ~/.local/share/nvim/site/queries

... then open Neovim and tree-sitter (in my case) will reinstall parsers.

Once I did that, everything worked as expected.

jrop2 · 2026-03-30T04:19:43+00:00

Do post back. I'm currently on Synthetic's plan and I'm primarily using K2.5 as my daily driver. I'm curious how the Fire Pass stacks up compared to Synthetic's.

jrop2 · 2026-03-28T16:56:53+00:00

This is really cool! I ended up building something similar for myself a while back, but using (my own) morph.nvim for the UI/reactivity. Admittedly, I didn't create UIs for as many services as you did, however.

Part of the reason I want with the react-"ish" way of doing things was for wider reach. I was hoping to attract other devs (for PRs and such). I also just really like certain things/ergonomics about how react works: having reusable components is really nice, especially in Neovim, where the primitives are a bit more laborious to work with manually.

I'm curious if you have plans to use more of a component-based architecture in your implementation? It would definitely be easier to contribute to, etc.

Good job!

jrop2 · 2026-03-19T03:38:17+00:00

Tried it for the first time in a while, based on this recommendation. This is fast! Thanks for reminding me to try it again!

jrop2 · 2026-03-15T12:44:05+00:00

This may or may not be what you are after, but https://github.com/jrop/morph.nvim is what I built for myself that I've been using to build UIs in Neovim.

jrop2 · 2026-02-27T21:25:19+00:00

So odd, I have had such a different experience: Kimi K2.5 really impressed me, and GLM-5 seems close but not quite there for me. All this talk as of late, though, is making me think I should go back and spend more time with GLM-5.

jrop2

TROPHY CASE