~konimarti


#224 Recursive parsing of attached messages 2 months ago

on ~rjarry/aerc

On Fri Feb 02, 2024 at 11:41, ~mcepl outgoing@sr.ht wrote:

On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:

  1. I don’t have m there, but that could be probably easily fixed in the configuration.
  2. I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.

I wonder why that happens? Oh right, if you reply to a picture attachment you would also get the raw image. This is a general property with parts. I guess you can use caeml to view and if you do want to reply, :eml (after Koni's new patch is applied).

#224 Recursive parsing of attached messages 2 months ago

Comment by ~konimarti on ~rjarry/aerc

On Fri Feb 2, 2024 at 11:41 AM CET, ~mcepl wrote:

  1. I don’t have m there, but that could be probably easily fixed in the configuration.

Apologies, you're right. m is not in the default binds.conf. You just see the line without the m key. I have m = :eml<Enter> in the [view] section of my binds.conf.

#224 Recursive parsing of attached messages 2 months ago

on ~rjarry/aerc

On Fri Feb 2, 2024 at 11:02 AM CET, ~konimarti wrote:

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:

  1. I don’t have m there, but that could be probably easily fixed in the configuration.
  2. I have started to play with Bence’s https://github.com/ferdinandyb/caeml and it looks pretty reasonable. Unfortunately, when replying to the shown message I get raw unencoded message to reply to, which is a little bit less useful.

#224 Recursive parsing of attached messages 2 months ago

Comment by ~konimarti on ~rjarry/aerc

Don't you already see a suggestion to open the rfc822 message with :eml. I get this option list on master for message/rfc822 attachments:

  O       Open using the system handler  :open<enter>
  S       Save to file                   :save<space>
  |       Pipe to shell command          :pipe<space>
  m       View message attachment        :eml<Enter>

So you should be able to just press m to view the attached message in a new message viewer tab?

#227 after opening a message with :eml, we should be able to reply to it 2 months ago

~konimarti assigned ~konimarti to #227 on ~rjarry/aerc

#219 regression: after archive the next selected message is the last message in the folder 2 months ago

Comment by ~konimarti on ~rjarry/aerc

On Sat Jan 27, 2024 at 1:57 AM CET, ~elshize wrote:

This actually doesn't happen for me with :archive but it it does on :mv Trash. Also using maildir, glanced over recent commits but nothing obvious (to me) jumped out.

I can also reproduce with :mv Trash on maildir.

Bisected to this recent commit:

commit 40c25caafd583d4ee6ab3f5b318306e534abe480 Date: Mon Jan 22 20:46:54 2024 +0100

mv: allow to move messages across accounts

#112 task view 2 months ago

Comment by ~konimarti on ~rjarry/aerc

Maybe there could even be some task hiearchy, such as if the workers run several subtasks at once, but it shouldn't get too complicated.

If you use contexts, the task hierarchy is build into the context structures.

Also, I forgot to mention (although it's in the original post) that the tasks should also ideally be stoppable, although that would probably require some cooperation from the tasks as I don't think it's quite possible to just stop a goroutine. But that would not be a good idea anyway, usually some clean up would be necessary, so the tasks would probably have to listen on a channel for a signal to exit prematurely. As such, there would probably be just a few exit points where the task would check if abort was requested and it would probably not be possible to force the task to exit in an arbitrary moment.

Did you have a look at https://git.sr.ht/~sircmpwn/dowork? This seems useful for dispatching, scheduling, restarting of failed tasks etc. and appears to cover most of the requirements.

#210 flag gets added on keybind press 2 months ago

Comment by ~konimarti on ~rjarry/aerc

I tried removing this line and it fixes the annoying popup but adding o = :rmdir<space><tab> does not trigger completion. Maybe we need to change something else.

I made the same observation after writing my inital response. This needs more analysis. But getting rid of this "magic" tab key seems worthwhile since it seems more like workaround than a fix.

I also have an idea for a quality of life fix in go-opt: flags should only be proposed in completion choices if the current word starts with a - what do you think?

I do like the current go-opt behavior, except that side effect that is probably related to that tab key.

#210 flag gets added on keybind press 2 months ago

bug added by ~konimarti on ~rjarry/aerc

#210 flag gets added on keybind press 2 months ago

Comment by ~konimarti on ~rjarry/aerc

I can reproduce it. A quick bisect points to commit b3dc63d6 ("complete: only display popover for more than one choice").

Aerc sends a tab after evaluating a keybind at app/aerc.go:290 to trigger the completion popover. However, with commit b3dc63d6 applied, the simulated tab key will complete the flag if it is the only option for the given command (as is the case for :rmdir -f).