mail view: moving up/down at top/bottom of list should not "re-open" mail

[frasertweedale]

Is your feature request related to a problem? Please describe. When you are already at the first/last email in a thread, and you "go to previous/next mail", you "move" to the same email, and lose your place in the mail.

Describe the solution you'd like We should detect that the target email is currently-open email, and NOT "re-open" it.

For UX bonus points, maybe we display (temporarily) an "already at first/last mail" message, like mutt does.

[romanofski]

Do you expect to go to the next mail in the thread? I'm currently not sure what you mean.

[frasertweedale]

@romanofski I mean, when you're at the top and move UP, or when you're at the end and move DOWN, you should not lose your place (i.e. how far down it you've scrolled) in the currently-open mail. Does this clear it up?

[romanofski]

To reproduce:

• Open a mail in which the content extends beyond the view port and is either the first or the last mail.
• Scroll down
• Press next mail again and mail content starts at the top again

[romanofski]

I had a quick look. The current implementation:

1. resets the scroll status
2. parses the email by using the the e-mail filepath
3. updates the AppState with the newly created MIMEMessage

There are a few options:

1. We parse the message into a MIMEMessage and then do an equality check. Only update the scroll state if the messages are not equal. Downside: incur the cost of actually parsing the message every time
2. We keep the NotmuchMail id of the current open mail somewhere in the AppState and do the equality check here. Upside: No additional parsing costs, but downside of the need to update another field.
3. Any chance to identify a NotmuchMail with a MIMEMessage we could mitigate the downsides of 1) and 2)

[frasertweedale]

@romanofski surely we can just perform the brick List move command and compare the index of previous and next list, or something along those lines...

[romanofski]

@frasertweedale the problem is, that the actions are "too well encapsulated" at this point. For example:

  Keybinding (V.EvKey (V.KChar 'k') []) (listUp `chain'` displayMail `chain` continue)

performs the listUp first and then performs the displayMail action. The actions are distinct from each other so that displayMail which resets the scroll state doesn't know the previous action performed a listUp. What that means is, from the viewpoint of displayMail, you just know what the selected scroll state is, not what it was. You'd have to know that in order to compare. Unless we introduce some concept of Context passed on to Actions which encapsulates the state before the change or something.

[frasertweedale]

@romanofski OK, so more work is needed then, e.g. a way to "abort" a chain of actions or something like that... just shelve this for now, I'll think about it some more :)