When we tell himalaya to list messages, and:

• --page is not 1
• --page-size is such that it exceeds the number of the remaining messages (e.g., we want to list 30 messages but only 27 are left)

himalaya fails with the following error:

> himalaya list -s 30 -p 10
Error: cannot fetch imap emails within uid range 5,4,3,2,1,0

Caused by:
    Bad Response: Command syntax error. sc=HsJvYEJQuSw0_080354_imap-production-862

(Here the number of the messages on page 10 is less than 30 -- i.e., 27)

If --page is not specified, and --page-size exceeds the number of messages available, then all the available messages are shown. Probably, should act the same when --page is added, just show all the remaining messages.

When listing messages, the -w option can to some extent decrease the width (by decreasing the Subject: column) but it seems it can't increase the width more that the auto detected one.

Which is a pity because we can't expand the listing to occupy the whole terminal (so that the columns would always be at the same place).

What do you think? May be it could simply widen with spaces the very same Subject: column when increasing?

Requires #114.

Don't know if it's just me but if I have the following in my binds.conf:

[messages]
D = :move Trash<Enter>
[messages:folder=Trash]
D = :delete-message<Enter>

Then the latter doesn't work (aerc still attempts to move messages to Trash despite this folder-specific binding).

~konimarti

Not really, as you will always have to start from the first unread message.

Let's say there are unread messages above and below the currently selected one. And then a user wants to jump to the next unread one. So, they start this search, but the cursor jumps to the first unread message, so then they'll have to call the :next-result command [quite] a few times.

On Sat Apr 22, 2023 at 7:47 AM CEST, ~skejg wrote:

Sometimes, when the emails are read not in the linear manner, having the commands (and the mappings) to go to the next or the previous unread message could be handy.

Couldn't you emulate this behavior by running a search for unread messages (:search -u) and use :next-result and :prev-result?

Sometimes, when the emails are read not in the linear manner, having the commands (and the mappings) to go to the next or the previous unread message could be handy.

Let's say the following msglist rules are defined:

# default msglist_* styles
msglist_default.fg                     = "#d3d3d3"
msglist_answered.fg                    = "#555555"
msglist_flagged.fg                     = "#00ff00"
msglist_deleted.fg                     = "#555555"
msglist_result.fg                      = "#ffaa00"
msglist_marked.fg                      = "#ffff00"
msglist_*.selected.reverse             = false
msglist_*.selected.bg                  = "#d3d3d3"
msglist_*.selected.fg                  = "#000000"
# dynamic msglist_* styles
msglist_default.From,~Robin.fg         = "#ff0000"
msglist_answered.From,~Robin.fg        = "#555555"
msglist_flagged.From,~Robin.fg         = "#00ff00"
msglist_deleted.From,~Robin.fg         = "#555555"
msglist_result.From,~Robin.fg          = "#ffaa00"
msglist_marked.From,~Robin.fg          = "#ffff00"

Which means that messages under the cursor should always be displayed as black on grey (#000000 on #d3d3d3). However, if a selected message is colored according to the dynamic rule shown above AND is answered (#555555) flagged (#00ff00), a result of a search (#ffaa00) or marked (ffff00, yellow) -- then its foreground color will stay as defined by the corresponding dynamic sub-rule.

Screenshots to illustrate:

• two dynamically colored messages vs two common messages: the cursor is black on grey, which is correct;
• all messages are marked, a common message selected: the cursor is black on grey, which is correct;
• all messages are marked, a message highlighted by the dynamic style selected: the cursor is yellow on grey, which seems to be wrong.

When notifications are enabled for a particular tracker, I do receive emails for every new ticket and comment from that tracker. With one exception: except for those that were authored by myself.

Of course, I sort of understand the logic here: why sent a person their own words? But since those notifications are just regular emails, it seems only logical to have the whole thread / discussion on a particular ticket at your disposal in your email client / archive / whatever. And the absence of my own replies (or even the original posts) makes this thread system quite broken.

We can't filter by the exact phrase, can we? Quotes, too, seem to have no effect. And even when filtering by {{.SubjectBase}}, for instance, the filter still looks for the words from the Subject, not for the exact expression.

Would be great to have this possibility, if possible.

To reproduce:

• run :term
• run cat ( or xxd)
• press the hotkeys in question
• note that the shifted arrows return the very same escape sequences as the non-shifted arrows, plain <Up> / <Down> / <Right> / <Left> (the arrow keys pressed together with the <Ctrl> or <Alt> modifiers work fine).

You can't also map <S-arrows> (returns, for instance, Failed to load config: Unknown key 'S-Up'), while you can map <C/A-arrows> (though the latter seems to be broken), but that's probably another problem.