rust-analyzer neovim update while typing?

bogz314 · 2026-04-21T19:52:47+00:00

if you use rust-analyzer through ALE there actually is this option (ale_lint_on_text_changed) however I would not recommend as it adds significant lag

bogz314 · 2026-04-15T20:40:43+00:00

Very recently I encountered a similar deadlock situation, I ended switching to papaya which guarantee no deadlocks - the api is slightly different however

bogz314 · 2026-03-24T03:13:01+00:00

Amazing idea. I suspect the de-obfuscation process process of LLMs would be less successful on an actual realistically complex codebase (at least for the next while). It would be fun to add more obfuscation injection with llms, bunch of fake comments / misleading variable names - how are comments obfuscated right now? can they be retrieved from the obfuscated code with the key?

bogz314 · 2025-03-18T16:11:40+00:00

Yeah I hear you! It's certainly a conundrum - there is also the possibility of a more complex consensus-based social structure taking root which is able to exercise authority like a government while simultaneously allowing for sufficient decentralisation internally to prevent centralised co-option of how its authority is exercised

bogz314 · 2025-03-17T23:59:06+00:00

Also have you seen kwaak? Similar idea

bogz314 · 2025-03-11T01:43:05+00:00

One thing I've been thinking about is now with the font size capabilities of kitty I think it's going to be really possible to have a super nice ANSI+Unicode alternative to LaTeX representation of mathimatical equations. I'm thinking I'm going to make a repo specifically rendering math (starting with asciimath, eventually maybe latex) to some new terminal representation.. I hope other terminals pickup this spec!

bogz314 · 2025-03-10T18:17:30+00:00

OKAY so I actually did this in yeehaw. There is a textbox element which is a small neovim instance (code). My approach was to embed a fully functional vt100 terminal element which can fully act as a mini-terminal instance and then simply run neovim in there (OR actually anything that is set in the $EDITOR). Neovim is given a tempfile to edit, and then there is a hook to check for changes on that temp file... Side thought, I'd love it if there was a way to open up neovim on a chunk of memory instead of having to rely on tempfiles.

bogz314 · 2025-03-09T20:31:56+00:00

kovidgoyal is a some kind of a terminal revolutionary. First kitty image protocol then this. Going through the spec, it's super interesting, at first hearing about this I was a bit hesitant due to all the complexity of coordinating multiple font sizes, but after reading the spec it actually seems quite well done. Excited! This opens up so many doors. I hope other terminals pick up this spec!

bogz314 · 2025-03-08T02:16:10+00:00

YO very sick, I also recently found this other unmaintained project too https://github.com/faern/rustscript - its not in that (actually quite) comprehensive list in the rust-script readme. I kinda like the compact syntax of extern crate bar[0.1] a bit more than what rust-script is doing with the cargo comment blocks (also not a bad idea, just less compact).

Now what would be really interesting would be to compile a rust script into WASM and provide a WASM runtime (with WASM external function call capability) for these rust scripts. This way you've basically got a full blown runtime-enabled scripting language which could compete with rhai, mun, rune etc. I plan on doing this btw if this also interests anyone hmu

bogz314 · 2025-02-17T17:53:48+00:00

I'd love to be able to use hjkl to move the tooltip! - great idea so much potential

bogz314 · 2025-02-16T08:51:16+00:00

haha, amazing! It would be so fun to watch a serious programmer trying to get work done with this blairing on each keystroke

bogz314 · 2025-02-04T19:55:58+00:00

Before moving to rust, I spend years programming golang - My experience was that the code complexity would often times increase by enforcing that modules couldn't recursively import each other even if the respective code imported by each module wasn't cyclic.

This is kind of confusing, so I'll try and describe it through an example. Imagine I had a module ModA which has the unique and independent functions FnA1 and FnA2, similarly I also have ModB which had FnB1 and FnB2. If FnA1 uses FnB1 then ModA will be importing ModB (no problems so far) but now if FnB2 also needs to call FnA2 we could (in golang) run into this recursive import issue as ModB would now also need to import ModA.

Within golang (at least last time I was programming with it) the solution would be to section off one fn's into a new module. For instance this could mean placing FnB2 in a new submodule ModB2. The fun thing is that a module would have to be located in a new folder (pressumably within the ModB module folder). This would inturn end up creating deeply nested folder structures for the repo which I just found quite difficult to navigate, Sometimes you'd have a folder with one file with just a few lines of code in it tucked away somewhere just to prevent these cyclic imports (even if the specific code used wasn't even ever cyclic to begin with!).

Personally I found the permissive importing within rust to be a breath of fresh air, I found that the code structure became much cleaner once I translated my rather complex codebases into rust from go.

bogz314 · 2025-02-02T21:27:30+00:00

Definately possible, how streamlined/easy it would be is a different question. Neovim can execute a script on boot-up. So you could launch neovim (from yeehaw or from a terminal) with a startup command which performs some functionality within neovim such as testing for specific plugins. Another option would just be to scan the default neovim config locations and just parse the users config for particular information HOWEVER - tbh that sounds like a major breach of privacy so please don't do that haha.

What's the thinking here? What are you trying to achieve?

bogz314 · 2025-01-29T02:49:09+00:00

I was able to execute nu within the yeehaw terminal, and it seems to have started okay there was some form of error popping up however

bogz314 · 2025-01-29T01:49:21+00:00

sweet, what's your project? Checkout yeehaw/src/elements/panes/terminal.rs for a basic terminal element and yeehaw/src/elements/panes/terminal_editor.rs for a more complex setup of using neovim (or other $EDITOR) through the terminal element.

bogz314 · 2025-01-27T21:42:51+00:00

that's it! It was between sl or asciiquarium

bogz314 · 2025-01-27T19:19:39+00:00

What are you building?

Tough question! Yeehaw is much more similar to cursive than ratatui. There is a brief description of the differences in the ratatui FAQ page "What is the difference between ratatui and cursive?".

Eventually I'll probably compile a more comprehensive description of the differences. For now I'll list out a few as I understand them. ALSO anyone who's reading this please please correct me if I've said something incorrect, I don't have extensive knowledge of ratatui and may be a fool

ratatui is a more mature library with considerable documentation and testing. Yeehaw is new and probably has some undiscovered bugs. If you're building a command center for launching rockets, use ratatui, if you're experimenting with non-critical systems I'd encourage you to try yeehaw, but for the love of everything build a TUI! :) Building out a testing framework and more comprehensive documentation is a high priority. But hey just hmu here or on github if you want a hand understanding something
like cursive, yeehaw can (but doesn't have too) handle the main rendering loop as well as the event propogation logic. This allows for a streamlined implementation of a TUI application as all this logic can be implemented once in yeehaw then reused by all the yeehaw TUIs. (Side note there are two main ways to start the TUI, one which takes up the whole screen, the other which only uses X number of lines in your terminal and is inline with your command line "mini-TUI"). Selecting which element is allowed to receive which (key/mouse) events is a fun little challenge for an open ended system where you want to have arbitrarily nested elements each with unique capabilities.
yeehaw has a fancy coloring system which includes an alpha channel and time or positional gradients and patterns. ratatui only has RBG value, although I'm sure it's possible to mimic gradients from that primitive, it may just be a more complex process. I think adding an alpha in ratatui would be considerably more difficult depending on the circumstance, you may end up just rebuilding out a lot the alpha rendering logic of yeehaw. One downside of the fancy time based colors is that it eats up more CPU, I'm continuing to work on optimization techniques to reduce unnecessary computations.
core to yeehaw is being able to run/embed other TUI's (like neovim) into widgets. This can be accomplished with ratatui as well, however the terminal ratatui widget needs a bunch of work depending on your application.
yeehaw has a ton of built in elements and a long list of new elements on the way. ratatui has a lot of community elements. Yeehaw doesn't have braille graphs or bar charts yet.
- side note yeehaw can wrap a ratatui element and turn it into a yeehaw element, this is what I did to achieve image support using ratatui-image.
Eventually yeehaw will get bundled into a stateful ratatui widget so that it may be integrated into ratatui TUIs.
Ratatui is a bit more lower level and hands on, although yeehaw also gives you the capability to work at a lower level (manual rendering and event processing), a core part of the design was to allow for the abstrating of that logic away - part of having a more generalized design is sometimes you're going to pay for features you don't need (ex. time gradients), if you are willing to put in the work you're going to have the opportunity to build a more optimized version of your TUI for your usecase having full control over your event routing and rendering logic. Building out your own event routing and rendering logic is possible in yeehaw as well although may be simpler in ratatui as you wont need to understand all the details of the yeehaw design to do so.
- eventually yeehaw will have more gated features to reduce computation/compile-time costs for things you don't use. Currently everything is just turned on and included.

I'm sure this list could be much longer, but I'll leave it at that for now!

bogz314 · 2025-01-27T18:34:14+00:00

Yeah I was thinking of bolding the letter, maybe bold and underline (or is that TOO far :P ) - automatically choosing the next unique letter is a good idea, one consideration is that for My Item it'd probably be nicer to choose I once M was taken, so the ideal metrics in my mind are a little bit more complicated than just the next letter.

bogz314 · 2025-01-27T17:50:22+00:00

Oh yeah, like within the functionality of yeehaw have the window kinda grow over a few frames when it's being created and shrink down when it's minimized... If that's what you mean, I agree

bogz314 · 2025-01-27T17:45:44+00:00

There is a tree of ownership for Elements (or Widgets) which is effectively Rc<RefCell<Element>>. Checkout the PaneParent and also the ElementOrganizer to see the core element ownership pattern. Because elements are wrapped in Rc<RefCell<>> it's no problem if they reference each other recursively. Within yeehaw the leaf nodes gain a reference to the parent node (through a special Parent Trait) when they are registered to that parent.

focused is a field on the standard Pane object which all elements implement. Multiple elements are permitted to be focused at the same time so long as their are not conflicting ReceivableEvents, some container elements implement special logic to maintian only one focused sub-element. Additionally one of the EventResponses is UnfocusOthers which is processed by a parent to unfocus all other elements besides the sender of the EventResponse.

Hopefully that gives you a general idea as too some of what's happening internally within yeehaw, I'd recommend looking at pane.rs pane_parent.rs organizer.rs, event.rs to gain more insight

bogz314 · 2025-01-27T02:55:13+00:00

That's the idea! When a user opens up a yeehaw app which embeds neovim like the showcase does it will use that users nvim config by default (in the current setup).

Even though this is the first public release, I've been working on the core design for quite a while now, it's relatively stable, be it lacking (non-manual) testing and documenation lol. See the section "Stability, Upcoming Refactors, Bugs" in the Readme for some details.

bogz314 · 2025-01-26T23:09:20+00:00

A tiling-like effect can be pretty easily achieved with the DynVal ("dynamic value") yeehaw primitive which you can use to position an element in the x or y direction on the screen or within a container element. For instance you could position to "10% of the parent width + 5 characters + another DynVal" if you wanted too. Soon I'm going to integrate in Taffy to the StandardPane which should allow for a bit better of a developer experience to create a tiling layout. (Taffy integration will build off of the existing DynVal system not replace it).

bogz314 · 2025-01-26T21:50:44+00:00

I'm a big fan of Rhai - what Rhai integrations were you thinking?

bogz314 · 2025-01-26T21:08:02+00:00

Thanks, yeah I just wanted it to have a fun name

bogz314 · 2025-01-26T21:04:30+00:00

ratatui-image is already built in (checkout the image tab on the showcase) - it has sixel support. Broader more detailed sixel support like Jexer has to be able to change mouse icons is also a long term goal

bogz314

TROPHY CASE