This looks very interesting. Are there any advantages to using it as opposed to neovim in a terminal?
I guess my question can be posed to any gui text editor. Still, nice project!
I guess my question can be posed to any gui text editor. Still, nice project!
There are a few examples in the GUI based disassemblers world (like IDA pro) which use graphical arrows to show where branch/jump instructions goto. The usefulness of those is enough to convince me that perhaps more research needs to be done in this direction.
There is also the small advantage of being able to have more than one font type/size on the screen. Your navigator panel can be a smaller font size, Your inline documentation viewer can use a variable-width font.
The counter-argument to all that is always: "Is it worth giving up the ability to be used in a terminal to add those few features?"
Everything else can be defined as "style" and gets very subjective. nvui looks like it has nice animations and smooth scrolling.
A very basic feature is that IDEs underlines in yellow for warnings and in red for errors, as well as show fix-it popups when hovering the mouse around the error area I don't believe a terminal can do that while keeping syntax highlighting no ?
E.g. here's a plugin for simple-term to add support for it: https://github.com/hexoctal/st-undercurl
The Kitty terminal has all kinds of graphics addons including coloured undercurls and images too:
https://sw.kovidgoyal.net/kitty/underlines/
Vim and NeoVim both support coloured undercurls too.
I updated some Emacs package recently and now it opens any errors in a list buffer.
Vanilla Vi users would use :make to populate the location list, and then :cn or :cp to navigate back and forth. :cope to open up the quick fix window where you can use all your regular VI keybindings to navigate. Enter opens the location under the cursor in your previous VIM split.
There are also plenty of plugins that add inline diagnostics. It's common to use bindings for navigating these that ape the spell check navigation bindings ]s and [s.
Or, :tag FunctionName (which has completion) to jump to a symbol.
Or, forward incremental search to jump to a string in a file.
I also have a plugin to invoke fzf, (\tb to search buffers and \t to search for files by name), but I don't use it that often.
VIM has many tools to navigate through text. Everyone's got their own preferred methods.
If I don't have the file active but it's open (very likely if I have a compile error for it), then I can foreground the buffer with :b myfile<CR>. Then :17 to jump to line 17.
If the file isn't open at all, either fzf (\t myfile) or just :e path/to/myfile.
The main downside of :make is that it's synchronous, which is why I sometimes build in a separate tmux pane.
- Splits I can drag around to move and resize with a mouse
- "Native" window tabs instead of terminal-style tabs
- A gvim-style menu bar with some operations for which I can't be bothered to remember the key combination.
So, overall, mostly mouse support and better discoverability. I've tried a few though and haven't really found what I'm looking for, open to suggestions :)
You can already use the mouse to resize splits in neovim, :set mouse+=a
> "Native" window tabs instead of terminal-style tabs
Which features would "native" tabs provide that aren't already available?
> A gvim-style menu bar with some operations for which I can't be bothered to remember the key combination.
Which operations would you put under the menu?
You can sync your system clipboard with vim, for example. This also works well with clipboard history apps like Alfred or CopyQ.
Also, :set mouse+=a solves the line number selection issue.
In ideal world: reordering, tearing off and merging.
> Which operations would you put under the menu?
Ostensibly, all of them?
That's an interesting idea. It sounds like it should be technically possible in the terminal too.
Same would go with drag copying text.
I'm not sure how to handle something like this in a terminal editor, unless the vim plugins are aware of it (but they're not, since they weren't written for it). In a non-terminal editor like nvui, the new window could be just a view into a buffer, but still running inside the one instance of vim, allowing these plugins to keep working transparently, even though now there are multiple windows.
I don't think this is something that's easily possible with terminals without rewriting all the plugins that might need to be aware of it.
The iTerm2/tmux integration show that's you can map TUI windows on to GUI windows including splits into new GUI windows.
It's actually possible to have both the TUI representation and GUI representation connected to the same remote tmux session.
now, that's a good one.
You might want to watch https://github.com/glacambre/nwin
Overall I like it a lot.