Paul Schoenfelder

@sleipnir It's certainly possible yes. It's also not like there is nothing to do at the moment, there is plenty yet to be done to flesh things out and improve...

That's going to change when the `error_in_core` feature stabilizes. In the meantime, we should use [this fork](https://github.com/ZcashFoundation/thiserror-nostd-notrait). I've introduced it in my assembler changes (hope to have those pushed tonight/tomorrow).

I mean, we can fork `thiserror` ourselves and make the same changes - with code gen of the `Error` trait disabled for no_std, so this isn't a question of it...

This happened to me today, what I'm observing is that when in insert mode, all input goes to the window in which insert mode was entered. Switching windows, even if...

Well it seems I'm mistaken, because I am currently fighting with it and both windows are in normal mode, so 🤷. There doesn't seem to be any rhyme or reason...

@JosephTLyons I've run into this several times, and I gotta be honest, it is absolutely infuriating. I'm happy to run various experiments and even try to contribute a fix if...

> If I understood everything correctly, the semantics you propose would be useful when addresses are static (or known at compile time). But for dynamic addresses, we'd still run into...

> ...I think we'd incur extra 6 - 7 cycles per element read in this code. This is better than 9 - 10 cycles per read...but it is not dramatically...

That's essentially the hang up. I think it is useful, and the PR is solid, but I'm hesitant to add a third party dependency, especially one needed for the test...

That's probably fine, if you'd like to put together a PR for that change. The only problem I can see is that you'll need to attempt connecting to each name...