Hey, pretty cool project you got there. Wondered if I could join in.

URL: https://world-playground-deceit.net/ Result: https://yellowlab.tools/result/h02a4ofupn (looks like it doesn't understand too modern CSS)

On Fri Sep 30, 2022 at 4:42 PM CEST, ~rockorager wrote:

I sent a patch that should fix this. Can you test it out?

https://lists.sr.ht/~rjarry/aerc-devel/patches/35712

-- View on the web: https://todo.sr.ht/~rjarry/aerc/67#event-207657

Nah, second point still fails, unless $ex = <:> is supposed to an undocumented default, in that case, it works fine.

@~q3cpma: re: open-link:

So if I have a open-overrides file in my aerc config dir with the following contents:

text/html; /path/to/preferred/browser %s

Both :open and :open-link could use that command, while if that file is missing, or exists without a text/html line, both will revert to xdg-open functionality. I believe in the average case, this would be the most convenient approach, but I'm almost certain someone will want different behavior between :open and :open-link, so ultimately, I think overriding the :open-link provider should be a one-liner in the primary config file, and have my open-overrides file only apply to :open.

On Thu Sep 22, 2022 at 3:26 AM CEST, ~bourgeois_bear wrote:

@q3cpma :open-link is not in my man doc. Is that for opening URLs?

@rjarry: as far as implementation goes, I think something like .mailcap, but for openers instead of filters--specifying mime type, command, flags (like %s & %t in man 5 mailcap). Unspecified mime types revert to xdg-open. How does that sound?

-- View on the web: https://todo.sr.ht/~rjarry/aerc/64#event-206643

Yeah, it's missing from the main man page, but aerc-config(5) does mention it.

On Mon Aug 1, 2022 at 11:44 PM CEST, ~konimarti wrote:

On Mon Aug 1, 2022 at 6:37 PM CEST, ~q3cpma wrote:

#1st bug

This discussion is not threaded because these messages lack the References header that aerc relies on for client-side message threading. Mutt seems to use the subject line when there is no References header available as a fallback.

I see.

#2nd bug Resize your terminal windows to be something like 10 lines

high and open aerc. The "[dev] Replace ranlib(1) calls?" thread isn't properly rendered until all messages have been displayed (by scrolling down or using G).

Client-side message threading only applies to the messages that have been fetched (i.e. were loaded in the message list) for performance reasons. It does not thread your entire mailbox. If this is required, server-side threading would be the only way for now until we have a message cache for the entire folder available. Server-side threading can be done with IMAP servers that support the THREAD extension or with the notmuch backend.

What's the caching situation? Does it fetch/cache only what's visible or a specific block size? I could imagine setting that to say "threads will contain at least the last N days".

In any way, it should be able to thread more than what's seen, at least a few weeks; that's really the point of threads, to group messages differently from the rest, despite their time spread.

Well, beggars can't be choosers, as they say.

On Mon Aug 1, 2022 at 11:44 PM CEST, ~konimarti wrote:

On Mon Aug 1, 2022 at 6:37 PM CEST, ~q3cpma wrote:

#1st bug

This discussion is not threaded because these messages lack the References header that aerc relies on for client-side message threading. Mutt seems to use the subject line when there is no References header available as a fallback.

I see.

#2nd bug Resize your terminal windows to be something like 10 lines

high and open aerc. The "[dev] Replace ranlib(1) calls?" thread isn't properly rendered until all messages have been displayed (by scrolling down or using G).

Client-side message threading only applies to the messages that have been fetched (i.e. were loaded in the message list) for performance reasons. It does not thread your entire mailbox. If this is required, server-side threading would be the only way for now until we have a message cache for the entire folder available. Server-side threading can be done with IMAP servers that support the THREAD extension or with the notmuch backend.

What's the caching situation? Does it fetch/cache only what's visible or a specific block size? I could imagine setting that to say "threads will contain at least the last N days".

In any way, it should be able to thread more than what's seen, at least a few weeks; that's really the point of threads, to group messages differently from the rest, despite their time spread.

Well, beggars can't be choosers, as they say.

On Mon Aug 1, 2022 at 6:37 PM CEST, ~q3cpma wrote:

Thanks for reporting this and sending the messages to test! Much appreciated!

#1st bug

The todo.sr.ht discussion with subject "Re: ~rjarry/aerc#65: Charset handling in filters" isn't threaded at all, while it is on neomutt (without thread root).

This discussion is not threaded because these messages lack the References header that aerc relies on for client-side message threading. Mutt seems to use the subject line when there is no References header available as a fallback.

We could consider bug #1 as a feature request for using the subject line when no References header is available.

#2nd bug Resize your terminal windows to be something like 10 lines

high and open aerc. The "[dev] Replace ranlib(1) calls?" thread isn't properly rendered until all messages have been displayed (by scrolling down or using G).

Client-side message threading only applies to the messages that have been fetched (i.e. were loaded in the message list) for performance reasons. It does not thread your entire mailbox. If this is required, server-side threading would be the only way for now until we have a message cache for the entire folder available. Server-side threading can be done with IMAP servers that support the THREAD extension or with the notmuch backend.

Using aerc-0.11 on Gentoo with the default config.

Here's a minimal maildir to reproduce it: http://0x0.st/oeTf.tar.gz Extract it somewhere ($HOME in the example) and temporarily add to your accounts.conf:

[Threading bug]
source = maildir://~/threading_bug
default = Inbox
from = dummy <dummy@dummy.net>

#1st bug

The todo.sr.ht discussion with subject "Re: ~rjarry/aerc#65: Charset handling in filters" isn't threaded at all, while it is on neomutt (without thread root).

#2nd bug

Resize your terminal windows to be something like 10 lines high and open aerc. The "[dev] Replace ranlib(1) calls?" thread isn't properly rendered until all messages have been displayed (by scrolling down or using G).

This ticket should also concern :open-link in some manner.

Title says it all, it could be helpful, especially as Emacs grabs a lot of useful <C-*> slots.