Messages disappear from header view before they are rendered

[Nicolas Richard]

Hello,

When I try to open a message, it sometimes takes a long time (stuck in
the *mu4e-loading* buffer) for some reason (which might be a bug itself,
but not necessarily a bug of mu4e). When I'm impatient, I simply stop it
with C-g. At this point the view buffer is empty, which I can
understand, but if I close it then the message which I was trying to
open is not in the headers view anymore : it seems it was marked as read
and already hidden. I don't really understand why it happens because
when messages are rendered properly, they're marked as read but are at
least kept in the headers view.

Could mu4e wait until the message is actually rendered before marking it
as seen/read ? If not, could mu4e at least avoid removing the message
from the headers view ? I usually forget which message I was trying to
read, so I have to browse recent (read) messages and hope to find wihch
one I didn't really read.

--
Nicolas

[Eduardo Mercovich]

Hi Nicolas.

> When I try to open a message, it sometimes takes a long time [...] When I'm impatient, I simply stop it

> with C-g. At this point the view buffer is empty, which I can
> understand, but if I close it then the message which I was trying to

> open is not in the headers view anymore [...]

What version of mu4e and emacs do you have?
I didn't saw that behaviour...


--
e

[Nicolas Richard]

It's a recent git build of mu/mu4e, and I follow the emacs-25 branch of
emacs -- both from a few weeks ago probably. If it's unknown behaviour
I'll try to make a reproducible recipe.

--
Nicolas

[Alexis]

i wonder if the current ongoing changes on the master branch
re. async DNS:

https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01348.html
[1]

might address this issue?


Alexis.

[1] A message which is the start of a very long thread!

[Dirk-Jan C. Binnema]

When you open an unread message, it's marked as read, then opened again
(with the updated status). If you C-g in between, then the old message
has already been removed but the new one is not there yet. Delays can
happen when the mu server is doing something else when you try to render
the message.

Problem is merely cosmetic, but you can of course file an issue in the
github tracker, so we won't forget it.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Nicolas Richard]

Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> writes:
> When you open an unread message, it's marked as read, then opened again
> (with the updated status). If you C-g in between, then the old message
> has already been removed but the new one is not there yet. Delays can
> happen when the mu server is doing something else when you try to render
> the message.

Thanks for the explanation. In my case I think it's usually shr being slow.

> Problem is merely cosmetic, but you can of course file an issue in the
> github tracker, so we won't forget it.

I'll do so.

For me, the problem is a real one because if messages I didn't read are
marked as read, I'll forget about them. I can't trust my brain for these
things. If there's a way to mark the message as read upon *exiting* the
message view buffer, that'd be lovely for me.

Nicolas.