~konimarti


#90 :next/:prev behavior in Message View a month ago

Comment by ~konimarti on ~rjarry/aerc

This has been implemented by commit c6463ba4

REPORTED RESOLVED CLOSED

#48 Support not marking messages as read when viewed a month ago

Comment by ~konimarti on ~rjarry/aerc

This feature has been implemented by commit e4d418ee

REPORTED RESOLVED IMPLEMENTED

#59 ui: deleting "last" message 3 months ago

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 is sort="date"

(well, my slice of uids is of the form [193 192 191 190 189 188 187 ... 2] after deleting the last message, but it's only when I hard-coded acct.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, findNextNonDeleted will never return nil. also, in my configuration, it seems to me findNextNonDeleted will return the message being deleted as the next one.

  • the stepFn is store.Next the first time around. - next first points at the message being deleted. - none of the first ifs matches and so stepFn is invoked and previous points at the message being deleted. - at the second iteration of the inner loop, next still points at the message being deleted (as stepFn will clip) - so the second if matches as previous == next. - so we break and go with stepFn==store.Prev. - there, next will still point at the message being deleted, previous==next and we break again, exit the outer loop.

we end up with next pointing at the deleted message.

previous should 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!

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

#18 style: allow styling individual message list fields 4 months ago

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.columns setting 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

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

#18 style: allow styling individual message list fields 4 months ago

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.columns setting 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

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

#18 style: allow styling individual message list fields 4 months ago

on ~rjarry/aerc

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.columns setting 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

#18 style: allow styling individual message list fields 4 months ago

Comment by ~konimarti on ~rjarry/aerc

On Mon Aug 1, 2022 at 11:59 AM CEST, ~rjarry wrote:

probably a new section in aerc.conf that 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?

#65 Charset handling in filters 4 months ago

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/html works 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