Budapest
imap added by ~ferdinandyb on ~rjarry/aerc
Ticket created by ~ferdinandyb on ~rjarry/aerc
Our imap backend triggers the new message hook via the imap server exposing \recent. If the server does not have this capability (looking at you gmail), it's pretty hard to know what is a new mail.
Some quotes from IRC:
I don't think we have a way to differentiate initial load from updates message infos arrive asynchronously you'd need a way to flag that a given folder has finished initial load to then trigger the hook on new messages but then, if you copy an old message from another folder or if you scroll down, you'll get notification every time
it is really complicated
maybe the less terrible solution would be to check the date but it is a hack anyway
Ticket created by ~ferdinandyb on ~rjarry/aerc
You need an email where From: and Sender: are different probably. From is decoded, Sender is not in the view. You may also need to use
header-layout=From,Sender,To,Cc,Bcc,Date,Subject,Labels
To see it.
Comment by ~ferdinandyb on ~rjarry/aerc
On Thu Nov 21, 2024 at 21:19, ~inwit outgoing@sr.ht wrote:
This would indeed solve viewing inline images in text/html parts with a sixel/kitty capable tui browser like chawan. Maybe it's better to define a [pagers] config section allowing different pagers for different filetypes? Could be an overshoot, but the | syntax as defined here is obscure to me.
That would be overkill and hard to reason about imho. The idea here is that you just mark that specific filter line you have that you will be providing the pager, aerc does not have to pipe it into the configured default pager.
Comment by ~ferdinandyb on ~rjarry/aerc
I am unable to reproduce this. I'm also not sure what a client can do if this were the case. We need to hand over the email for sending to the smtp server. If the server can't handle bcc then the only workaround I could see is sending several messages instead of one.
~ferdinandyb, ~justinesmithies
With 0.18.2, folder-specific bindings certainly seem to work, if I'm not mistaken.
However, the command
:delete-messageitself acts strange for me: in a Gmail account, it only deletes messages if run in[Gmail]/Trashfolder. In any other folder (or, label in Gmail's vocabulary), it just deletes a message from the current folder (strips the current label from an email).Sadly, I don't recall it already, but it's possible it was the command's behaviour (different at the time of submission), not the folder-specific bindings per se, that was the reason for my original report (I don't remember if I only had this one folder-specific binding back then and if I tested it with other mappings).
Anyway, as the title stands now, it probably can be closed?
Comment by ~ferdinandyb on ~rjarry/aerc
Ideally, any extra you'd type would be passed to it, e.g.:
define gitsendinreplyto = term git send-email --cc='{{.Cc | persons | join "' --cc='"}}' --annotate --cover-letter --in-reply-to={{.MessageId}}And you should be able to call:
:gitsendinreplyto -v3 -2To send a v3 of the last two commits.