The title is pretty self-explanatory.

At first, I thought this was caused by the extra space in the bind
definition, since the popup was triggered if I did <C-l> then deleted
one of the spaces. However, I fixed that and it still didn't trigger the
popup.
I could contribute a patch, but I'm unsure what the issue here is.

Thanks
~tmpod

Really solid update for aerc!
Even though it's not directly included in the changelog, I noticed a 
significant improve in message fetching. Maybe it has to do with the 
race conditions?
Either way, awesome work from everyone involved, congrats!

Thank you.
~tmpod

Congrats on a new wonderful release!

> There's a way to that correctly, right? Or should I just send the entire 
> diff so that it shows up in each new version of the patch, for context's 
> sake?

Yeah, you should just send the diff in its entirety, afaik. `git send-email`
will put the commit message at the top, then the diff, with the option to put
on a cover letter between the commit message and the diff. I believe that is
the only place you should edit things.

Also, it seems like something broke with the mailing list's patch
recognition; it doesn't show diff hightlighting nor the usual patch controls.
Did you send the patch by standard means?

> and perhaps add a better VM constructor for debugging

For sure. I'm not very sold on `VM::new(bool)` and `VM::with_debug()`,
because they create some asymmetry. There's an "easy" way to create a VM with
debugging on, but there's none for no debugging. Maybe it's best to simply
not include the latter constructor. What do you think?

> Alright, got that fixed.
> We're probably going to want to switch to 
> logging instead of stderr printing, but 
> this will do for now.

Yeah, agreed.

> Debugging inside the CPU would involve passing around the debug flag
> and the stderr lock into the CPU module, which seems simple enough,
> but might get unhandy, especially since StderrLock has an associated
> lifetime, which might propagate some complexity.

Well, that ain't great, but I'm not seeing a way around it. At least not an
immediate one.

> I'm not sure if there's a better way of handling it as of now,
> but if you've got any debug design you'd rather implement, I'm all 
> ears.

I'm not exactly pursuing raw performance with this VM, but I somewhat worry
about the implications of the extra function call and branching on every

Btw, forgot to mention that I have created a public inbox mailing list and
that should now house all patches to smaller projects like these ;)

> -    // Load
> +
> +    /// Load
> +    //// Loads a value from memory into a destination register
> +    //// at an address offset from the PC.
>      LD(Register, u16),

Four slashes instead of three here ;)

Looks good otherwise, thank you!

Applied, thanks!

To git@git.sr.ht:~tmpod/brainfucc
   ..  master -> master