Ticket created by ~tardypad on ~rjarry/aerc
This follows the mailing list "discussion" https://lists.sr.ht/~rjarry/aerc-discuss/%3CCSLCE7V6PBJA.THVFF075ARCT%40walnut%3E#%3CCUCSBPWQPMTR.1YRS06PUGJK6G@walnut%3E.
When using a maildir account, at startup, unread "current" messages in subfolders (in maildir terms, the ones within the "cur" directories that contains mails "seen" by aerc before) are displayed correctly. However completely new (so also unread) messages in subfolders (in maildir terms, the ones within the "new" directories) are not displayed.
Comment by ~tardypad on ~tardypad/wee-most
Damien Tardy-Panis referenced this ticket in commit d2c5a3c.
REPORTED RESOLVED IMPLEMENTED
Comment by ~tardypad on ~tardypad/wee-most
A failure to download a file is already informed to the user via an error message in the server buffer
Comment by ~tardypad on ~tardypad/wee-most
Damien Tardy-Panis referenced this ticket in commit 76eacca.
REPORTED RESOLVED FIXED
Comment by ~tardypad on ~tardypad/wee-most
Actually the web client also:
- trims leading newlines
- replaces multiple consecutive newlines in the text with a single one
We'll just trim leading and trailing newlines, which can more easily happen by mistake. Consecutives newlines inside the text are most likely intentional.
Comment by ~tardypad on ~tardypad/wee-most
This is now fixed with the new way to detect unread posts and the refactor of fetching them. (see commits https://git.sr.ht/~tardypad/wee-most/commit/733de2ab605c8c461e0aa6516b5e4d3ee22c59ae and https://git.sr.ht/~tardypad/wee-most/commit/232521b436d3dc2bc726996b84c9f075dd15e354)
Previously the initial status was set to "read" for all posts coming from
posts/unread?limit_after=1and "unread" for the ones after. But actually in the first call https://api.mattermost.com/#tag/posts/operation/GetPostsAroundLastUnreadlimit_afteris "Number of posts after and including the oldest unread post" so the status was set wrong for that oldest unread item.The bug was actually present in all types of channels but was more visible in DM channels where there is less noise.
REPORTED RESOLVED CLOSED
bug added by ~tardypad on ~tardypad/wee-most
Ticket created by ~tardypad on ~tardypad/wee-most
render_message function assumes that the attachments of a message cannot be modified and thus that they will use the same number of lines as before when a message is edited. But this is not true as for example a poll will update its attachment with the results (which can then become longer than initially)
We then need to remove this assumption and refactor this function.