Interesting for the “GIF” section to have links to .mp4 videos — the “GIF” word now seems to be synonymous to short playable animations. Love that the author did that though, I’ve seen too many repos with multiple giant (~10MB) GIFs on the README and burn my mobile data plan.
I really dislike situations like this where the inferior becomes a name for the category, because it encourages people to keep using the inferior, often because that’s all they hear of and so all they know. “RSS” for feeds is a similar, though somewhat less bad, case (Atom is unequivocally superior, but in ways that seldom make a difference for most consumers for most content).
(Admittedly, actual video codecs are more a minefield, as is seen here in the video not playing in most environments due to the use of full 4:4:4 chroma, whereas GIF is simple and stupid enough that it’s consistent.)
Hey this is super cool, but can it work without the floating windows? Can I assign seditors to regular vim splits (am I using the terminology correctly?).
The narrow functions in Emacs were great, and almost made me switch to Emacs. I know NrrwRgn exists, but it didn't automatically sync the buffers, so you couldn't have them open side by side. This looks better, but I don't like the automatic layout stuff. I prefer to control that myself.
this already works, just use `YodeCreateSeditorReplace`. The command creates a seditor and opens it in the current window. You can then use the created seditor like any other buffer. To open a selected code part in normal splits do:
What’s the advantage of this over creating splits and navigating to the relevant code? This is what I do all the time, having a hard time understanding how this would improve that.
Splits are not based on content, but are controlled by a layout algorithm. For horizontal splits, for example, the size changes every time you create a new one. Yode-Nvim is based on the size of the seditors and enlarges/reduces them automatically. There are more layouting algorithms planned and they can be different for each tab, the code is already set up for that.
I wonder, as a general feeling, does the implementation of the floating narrowed regions involve a lot of hacks/workarounds, or does it come fairly naturally to nvim?
Well you can hide the rest of the buffer and focus on a specific part of a file with the narrow-to-* functions (defun, region, or page).
However, this plugin seems to be a little fancier and instead creates different buffers for each selection. The analogous feature set in Emacs are indirect buffers. Try binding a key to run the clone-indirect-buffer and narrow-to-region commands in sequence.
Yode-Nvim can create more regions of the same file as well as a floating "window manager" for regions called "layout". Yode-Nvim syncs changes from regions to files in real time where you need to "write" the changes by hand with NrrwRgn.
Yode (the POC 4 years before) itself only worked with a (JavaScript) AST to create seditors. Tree-sitter would have helped here to provide an AST for different programming languages uniformly directly in NeoVim. Yode-Nvim is more powerful than the first version because it operates on lines to create seditors. In this respect Tree-sitter doesn't matter for Yode-Nvim. If someone uses Tree-sitter to select code in visual mode, he can easily create seditors for code objects like functions. This is also possible without Tree-sitter, but you have to select the function yourself.
Interesting for the “GIF” section to have links to .mp4 videos — the “GIF” word now seems to be synonymous to short playable animations. Love that the author did that though, I’ve seen too many repos with multiple giant (~10MB) GIFs on the README and burn my mobile data plan.