~q3cpma

Trackers

~q3cpma/haggle

Last active 2 years ago

~q3cpma/mangadex-tools

Last active 2 years ago

~q3cpma/mus

Last active 2 years ago

#67 Variable $ex handling in compose::editor 2 months ago

Comment by ~q3cpma on ~rjarry/aerc

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.

#64 :open, but with ability to specify handler? 2 months ago

on ~rjarry/aerc

@~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.

#64 :open, but with ability to specify handler? 2 months ago

Comment by ~q3cpma on ~rjarry/aerc

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.

#70 Two threading bugs 4 months ago

on ~rjarry/aerc

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.

#70 Two threading bugs 4 months ago

Comment by ~q3cpma on ~rjarry/aerc

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.

#70 Two threading bugs 4 months ago

on ~rjarry/aerc

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.

#70 Two threading bugs 4 months ago

Ticket created by ~q3cpma on ~rjarry/aerc

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).

#64 :open, but with ability to specify handler? 4 months ago

Comment by ~q3cpma on ~rjarry/aerc

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

#68 Alt key combination (<M-*>) handling in bindings 4 months ago

Ticket created by ~q3cpma on ~rjarry/aerc

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

#67 Variable $ex handling in compose::editor 4 months ago

Ticket created by ~q3cpma on ~rjarry/aerc

Using the default binds.conf and changing the value of $ex under [compose::editor] brings different results (found by using emacs -nw as editor):

  • Default value (<C-x>): <C-x> brings the command prompt, : is passed to emacs.
  • Line removed from config: <C-x> is passed to emacs, but : brings the command prompt when it shouldn't.
  • <C-a> or <C-b>: : is passed to emacs, but <C-a>/<C-b> is also passed to emacs, when it should bring the prompt.
  • <Esc>: everything works as expected, : is passed to emacs and <Esc> does bring the command prompt.