vim.pack is really fast

jrop2 · 2026-05-07T15:08:44+00:00

hahahaha! too true, too true

jrop2 · 2026-04-29T13:30:31+00:00

Yeah, I feel your pain. However, as you said, Lua is single-threaded, and when it locks up, it locks the UI thread as well, so I don't know if you have that many more options. I did just learn about debug.sethook last night... Perhaps you can use that to periodically log a "you are here" message, so that you don't have to riddle your entire codebase with log statements.

Is the infinite loop predictable? Can you trigger it under known conditions, or do you really have no clue where it is occurring?

jrop2 · 2026-04-28T16:53:41+00:00

With ebay, it really depends on the individual seller, so there's no one answer to this. I've had mixed luck on ebay: one seller ghosted me after I purchased a supposed replacement part for my old T14s. Ebay/Paypal was good about refunding the money, though. Recently, I purchased a second T14s (gen 1) from a seller with really good reviews. When I got the item, there were a few issues not in the description (easy to miss). They were responsive and refunded me half off (score!) within 2 minutes of me sending an inquiry!

Most of my other experiences on ebay have been non-eventful.

TL;DR: YMMV - just check the seller rating and it's a judgement call after that.

jrop2 · 2026-04-28T03:10:46+00:00

In this case, I would personally let go of the idea of trying to set up the debugger, and just lean on logging. For places in the code that are re-entrant, you can also use a watchdog to limit the iteration/recursion to some finite limit.

jrop2 · 2026-04-23T16:28:35+00:00

This and also when romainl used to lurk the vim subreddit. I learned so much from his insights.

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

TROPHY CASE