I love NeoViM and have been using it for years (thanks to the developers and contributors!). To me, the only advantage ViM still holds over NeoViM is that it can :smile out of the box.
There are also quite a few QoL improvements for using Lua (e.g. better support for calling Vim functions, setting options, running commands, etc.), as well as some more niche improvements (e.g. the extmarks API, improvements to how native packages work, etc.). 0.5 is going to be an excellent release; I’ve been using (and developing plugins against) git HEAD for a while now, and it’s been a great experience.
I’m periodically stumbling into a layout bug when using :grep in neovim a lot; I would like to report to them a reproducible issue, but for that I’d need some kind of setup with easy way to script it and to capture “simulated screen” (headless terminal emulator? vm or a full cpu emulator like bochs sounds like an overkill… but even if, are they easily scriptable & easy to capture the on-screen text?). Does somebody by chance know of something that could help me? Ideally, I’d also love to use something like that for testing in my own TUI projects…
Riiiight; I do also know of the venerable if confusingly named script tool which is a kinda predecessor to ASCIInema; but the headless and scripting aspects are especially crucial here I believe, so that it could be easily rerun as part of continuous integration; also it seems to be somewhat nondeterministic behavior, that’s why scripting would be important to me, to be able to detect “the moment” when this happens… I don’t think ASCIInema has support for running headless (i.e. tty emulation/simulation)?
Ohhh, interesting, thanks! Hm, do I understand it correctly, that the pynvim package basically serves as a fake GUI for the neovim “core”? This made me realize, that I’m not actually sure if the bug I’m seeing is in the core, or in the TUI! I did seem to have nvim crash occasionally after this bug, so I’m kinda assuming it may be some memory corruption; do you know if there’s a way to discover if a nvim crash was in the TUI process or in the core process?
Hm, do I understand it correctly, that the pynvim package basically serves as a fake GUI for the neovim “core”?
Yes and no: the pynvim package serves as a true GUI for the neovim core :). Neovim has an RPC interface that lets you control neovim from another process. This RPC interface is exposed by libraries named “API clients”. These API clients are used by nearly all Neovim GUIs and allow building interfaces just as powerful as the TUI (there’s even a saying one of Neovim’s maintainers likes to say: “The TUI is just another GUI”).
do you know if there’s a way to discover if a nvim crash was in the TUI process or in the core process?
You could try to reproduce the crash from a GUI or continuously running neovim with a debugger attached (or core dumps enabled). I don’t know if there are other alternatives, I haven’t contributed much to neovim yet :).
Since you have the other bits running - https://github.com/letoram/nvim-arcan
that’s “most” of the UI side (no multigrid etc. yet) from a C angle, can try reproducing there.
Thanks; interesting idea, though as much as I do have the other bits running, I’m far from feeling at home with them yet :) I noticed that there seems to be some other TUI for vim mentioned in the OP announcement, maybe I’ll try to use it in my daily flow and see if the issue shows up or not.
Thanks, though… expect was basically one of the first things I thought about, but after checking the docs, I wasn’t really able to find a subcommand that would let me dump the internal buffer for interactive previewing :( and given that the bug is kinda weird, it would be hard to script it “blindly”… if you know how to make expect give me a dump of the app screen, and at multiple “points” in the script, I’d be super grateful if you could help me discover how to do that!
I love NeoViM and have been using it for years (thanks to the developers and contributors!). To me, the only advantage ViM still holds over NeoViM is that it can :smile out of the box.
…how have I been using vim for almost 20 years and never known about this?
That’s because it’s a fairly recent change (happened in the past five years IIRC) :).
Correct, it was introduced very close to 5 years ago:
The article mentions LSP client and tree sitter integration for 0.5, that’s quite exciting!
I’ve been using the nightly builds for a while and it has been great!
There are also quite a few QoL improvements for using Lua (e.g. better support for calling Vim functions, setting options, running commands, etc.), as well as some more niche improvements (e.g. the
extmarks
API, improvements to how native packages work, etc.). 0.5 is going to be an excellent release; I’ve been using (and developing plugins against)git HEAD
for a while now, and it’s been a great experience.I’m periodically stumbling into a layout bug when using
:grep
in neovim a lot; I would like to report to them a reproducible issue, but for that I’d need some kind of setup with easy way to script it and to capture “simulated screen” (headless terminal emulator? vm or a full cpu emulator like bochs sounds like an overkill… but even if, are they easily scriptable & easy to capture the on-screen text?). Does somebody by chance know of something that could help me? Ideally, I’d also love to use something like that for testing in my own TUI projects…Check out ASCIInema for capturing terminal output. For scripting though you would need to use external tools.
Riiiight; I do also know of the venerable if confusingly named
script
tool which is a kinda predecessor to ASCIInema; but the headless and scripting aspects are especially crucial here I believe, so that it could be easily rerun as part of continuous integration; also it seems to be somewhat nondeterministic behavior, that’s why scripting would be important to me, to be able to detect “the moment” when this happens… I don’t think ASCIInema has support for running headless (i.e. tty emulation/simulation)?If the bug you’re experiencing can be reproduced in a GUI, you could try to write a reproducer in python, like this.
Ohhh, interesting, thanks! Hm, do I understand it correctly, that the pynvim package basically serves as a fake GUI for the neovim “core”? This made me realize, that I’m not actually sure if the bug I’m seeing is in the core, or in the TUI! I did seem to have nvim crash occasionally after this bug, so I’m kinda assuming it may be some memory corruption; do you know if there’s a way to discover if a nvim crash was in the TUI process or in the core process?
Yes and no: the pynvim package serves as a true GUI for the neovim core :). Neovim has an RPC interface that lets you control neovim from another process. This RPC interface is exposed by libraries named “API clients”. These API clients are used by nearly all Neovim GUIs and allow building interfaces just as powerful as the TUI (there’s even a saying one of Neovim’s maintainers likes to say: “The TUI is just another GUI”).
You could try to reproduce the crash from a GUI or continuously running neovim with a debugger attached (or core dumps enabled). I don’t know if there are other alternatives, I haven’t contributed much to neovim yet :).
Thanks!
Since you have the other bits running - https://github.com/letoram/nvim-arcan that’s “most” of the UI side (no multigrid etc. yet) from a C angle, can try reproducing there.
Thanks; interesting idea, though as much as I do have the other bits running, I’m far from feeling at home with them yet :) I noticed that there seems to be some other TUI for vim mentioned in the OP announcement, maybe I’ll try to use it in my daily flow and see if the issue shows up or not.
Maybe expect solves this for you.
Thanks, though…
expect
was basically one of the first things I thought about, but after checking the docs, I wasn’t really able to find a subcommand that would let me dump the internal buffer for interactive previewing :( and given that the bug is kinda weird, it would be hard to script it “blindly”… if you know how to makeexpect
give me a dump of the app screen, and at multiple “points” in the script, I’d be super grateful if you could help me discover how to do that!Oct 2020?
Yes, newsletters for 0.3 and 0.4.4 were sent a bit late. They’ll try to do better for 0.5, which should be released this month :).
why do .io websites always look like bullshit
What’s wrong with how it looks?
It was a first impression but now that I look closer, it is the web fonts and gray tones instead of black/white.
Looks fine to me, what’s bothering you?
It was a first impression but now that I look closer, it is the web fonts and gray tones instead of black/white.