Comment by ~konimarti on ~rjarry/aerc
This has been implemented by commit c6463ba4
REPORTED RESOLVED CLOSED
Comment by ~konimarti on ~rjarry/aerc
This feature has been implemented by commit e4d418ee
REPORTED RESOLVED IMPLEMENTED
Comment by ~konimarti on ~rjarry/aerc
On Wed Aug 10, 2022 at 5:05 PM CEST, ~sbinet wrote:
this issue is back.
it seems to come from: https://git.sr.ht/~rjarry/aerc/commit/8f7695fde5cd84b7f6b8f3193270eda2fd62448c
first of all, I think
acct.Messages().Select(0)will select the first message when the sorting criteria issort="date"(well, my slice of
uidsis of the form[193 192 191 190 189 188 187 ... 2]after deleting the last message, but it's only when I hard-codedacct.Messages().Select(len(store.Uids()) - 1)that I got the expected behaviour)Yes, acct.Messages().Select(0) is a bug and should be acct.Messages().Select(-1) to select the last message.
besides, when the message store isn't empty,
findNextNonDeletedwill never returnnil. also, in my configuration, it seems to mefindNextNonDeletedwill return the message being deleted as thenextone.
- the
stepFnisstore.Nextthe first time around. -nextfirst points at the message being deleted. - none of the firstifs matches and sostepFnis invoked andpreviouspoints at the message being deleted. - at the second iteration of the inner loop,nextstill points at the message being deleted (asstepFnwill clip) - so the secondifmatches asprevious == next. - so webreakand go withstepFn==store.Prev. - there,nextwill still point at the message being deleted,previous==nextand webreakagain, exit the outer loop.we end up with
nextpointing at the deleted message.
previousshould be set to nil after the first loop according to your analysis.I guess we have to rethink that delete function again. But in the meantime, could you maybe test those three changes with your setup to see if the problem is fixed:
diff --git a/commands/msg/delete.go b/commands/msg/delete.go index ceb570b..59654c8 100644 --- a/commands/msg/delete.go +++ b/commands/msg/delete.go @@ -58,7 +58,7 @@ func (Delete) Execute(aerc *widgets.Aerc, args []string) error { // no more messages in the list if next == nil { aerc.RemoveTab(h.msgProvider) - acct.Messages().Select(0) + acct.Messages().Select(-1) acct.Messages().Invalidate() return } @@ -76,7 +76,7 @@ func (Delete) Execute(aerc *widgets.Aerc, args []string) error { if next == nil { // We deleted the last message, select the new last message // instead of the first message - acct.Messages().Select(0) + acct.Messages().Select(-1) } } case *types.Error: @@ -97,6 +97,7 @@ func findNextNonDeleted(deleted []uint32, store *lib.MessageStore) *models.Messa var next, previous *models.MessageInfo stepper := []func(){store.Next, store.Prev} for _, stepFn := range stepper { + previous = nil for { next = store.Selected() if next != nil && !contains(deleted, next.Uid) {Thanks!
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.
Comment by ~konimarti 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.
Comment by ~konimarti on ~rjarry/aerc
On Mon Aug 1, 2022 at 12:33 PM CEST, ~rjarry wrote:
~konimarti, Aug 01, 2022 at 12:19:
Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?
About "ui grid column". In my previous example, I thought exactly the same. Each element in the
message-list.columnssetting would live in its own column with an optional width specifier.[message-list] # 20% of the total width of the message list block # / 30% of the total width of the message list block # | / exactly 3 characters # | | / automatic width # | | | / # | | | | # v v v v columns=date:20%,sender:30%,flags:3,subjectExactly. I would just try to parse the existing index-format field to your column design (if no width/precision is specified, then the column width is set to ui.SIZE_WEIGHT otherwise to ui.SIZE_EXACT with the width given in the fmt specifier. Wouldn't that work? This means of course a complete rewrite internally but we could preserve the current configs.
On Mon Aug 1, 2022 at 12:33 PM CEST, ~rjarry wrote:
~konimarti, Aug 01, 2022 at 12:19:
Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?
About "ui grid column". In my previous example, I thought exactly the same. Each element in the
message-list.columnssetting would live in its own column with an optional width specifier.[message-list] # 20% of the total width of the message list block # / 30% of the total width of the message list block # | / exactly 3 characters # | | / automatic width # | | | / # | | | | # v v v v columns=date:20%,sender:30%,flags:3,subjectExactly. I would just try to parse the existing index-format field to your column design (if no width/precision is specified, then the column width is set to ui.SIZE_WEIGHT otherwise to ui.SIZE_EXACT with the width given in the fmt specifier. Wouldn't that work? This means of course a complete rewrite internally but we could preserve the current configs.
Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?
About "ui grid column". In my previous example, I thought exactly the same. Each element in the
message-list.columnssetting would live in its own column with an optional width specifier.[message-list] # 20% of the total width of the message list block # / 30% of the total width of the message list block # | / exactly 3 characters # | | / automatic width # | | | / # | | | | # v v v v columns=date:20%,sender:30%,flags:3,subject
Comment by ~konimarti on ~rjarry/aerc
On Mon Aug 1, 2022 at 11:59 AM CEST, ~rjarry wrote:
probably a new section in
aerc.confthat would look something like this:[message-list] columns=date:20%,sender:30%,flags:3,subject date={{.Date | DateFormat}} sender={{.Sender}} flags={{.Flags}} subject={{.Subject}}Such a change would break all existing aerc configs out there.
I kind of like the current index-format since it is very expressive and easily customizable by the user but I also see the shortcomings in terms of formatting.
Couldn't we improve the index-format parser so that each format specifier lives in its own ui grid column with its own styleset?
Comment by ~konimarti on ~rjarry/aerc
On Sat Jul 30, 2022 at 8:07 PM CEST, ~q3cpma wrote:
Using
text/html=w3m -dump -I UTF-8 -T text/htmlworks fine, so maybe we can assume UTF-8 as input always? w3m was originally choking on it because the header announced latin-1, I guess.Yes, I think that's correct. I'm almost a 100% that aerc always provides UTF-8 data to the filters since we use the go-message 0 package internally which automatically decodes the charset to UTF-8.
-- View on the web: https://todo.sr.ht/~rjarry/aerc/65#event-191643