Comment by ~konimarti on ~rjarry/aerc
On Thu Aug 3, 2023 at 9:06 PM CEST, ~ferdinandyb wrote:
sort="" sort-thread-siblings=true threading-enabled=true [ui:folder=Inbox] sort="-r date" [ui:folder=Archive] threading-enabled=falseand Archive is threaded, while nothing is sorted, so I'd say both are still problematic.
Ah, yes. I've tested the threading the other way around and that works (it's that old topic about merging zero values in the config).
threading-enabled=false [ui:folder=Archive] threading-enabled=trueI have an idea. I'll look into this.
On Thu Aug 03, 2023 at 14:42, ~konimarti wrote:
I can confirm that contextual sort per folder still doesn't work. The sort config is taken from account.GetSortCriteria() that would only respect the selected folder and not the specific folder for which the message store is being created.
However, it seems that the threading per folder has been fixed in the meantime, can you confirm this?
I have the following settings:
sort="" sort-thread-siblings=true threading-enabled=true [ui:folder=Inbox] sort="-r date" [ui:folder=Archive] threading-enabled=falseand Archive is threaded, while nothing is sorted, so I'd say both are still problematic.
Comment by ~konimarti on ~rjarry/aerc
Do you use an account-specific binding for messages as well (e.g. [messages:account=..])?
Using just folder-specific bindings seem to work fine on my end on the current master. However, it breaks when using it together with an account-specific one I'm wondering if that's the bug you see or if it's something else?
~konimarti assigned ~konimarti to #121 on ~rjarry/aerc
Comment by ~konimarti on ~rjarry/aerc
I can confirm that contextual sort per folder still doesn't work. The sort config is taken from account.GetSortCriteria() that would only respect the selected folder and not the specific folder for which the message store is being created.
However, it seems that the threading per folder has been fixed in the meantime, can you confirm this?
Comment by ~konimarti on ~rjarry/aerc
Ok, makes sense.
On Fri May 12, 2023 at 22:42, ~konimarti wrote:
I don't think we need a folder map for this. We can already handle this using templates in the
dirlist-leftconfig. For example, you could do the following:dirlist-left = {{if (eq .Account "Gmail")}} \ {{- .Folder | exec "sed 's/\\[Gmail\\]\\///'" -}} \ {{else}} \ {{- .Folder | compactDir -}} \ {{end}}However, this is currently super slow because the dirlist is redrawn so many times and it's an external command. A better approach would be to add a template function such as 'replace' and map it to strings.ReplaceAll:
{{- .Folder | replace "[Gmail]/" "" -}} \Or the
filepath.Basefunction could be an option, too.What do you think?
This solution only rewrites the display name, but leaves the actual name (the one that can be used with commands like :cf) the same. I think that actually makes the situation a bit worse, because it just hides whatever is underneath. My goal is to be able to completely remap the folder so if I have a [GMAIL]/label -> label remap, then all aerc commands would operate on "label" instead of [GMAIL]/label.
Comment by ~konimarti on ~rjarry/aerc
I don't think we need a folder map for this. We can already handle this using templates in the
dirlist-leftconfig. For example, you could do the following:dirlist-left = {{if (eq .Account "Gmail")}} \ {{- .Folder | exec "sed 's/\\[Gmail\\]\\///'" -}} \ {{else}} \ {{- .Folder | compactDir -}} \ {{end}}However, this is currently super slow because the dirlist is redrawn so many times and it's an external command. A better approach would be to add a template function such as 'replace' and map it to strings.ReplaceAll:
{{- .Folder | replace "[Gmail]/" "" -}} \Or the
filepath.Basefunction could be an option, too.What do you think?
~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-resultcommand [quite] a few times.
Comment by ~konimarti on ~rjarry/aerc
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?