mu4e-headers-mark-for-something handles region inconsistently/wrong

[mbunkus]

Expected or desired behavior

Generally I'm using transient-mark-mode. In mu4e I open a header view. Now I select a couple of messages by pressing C-SPC and moving point around. Several lines appear marked due to transient-mark-mode.

Now I use mu4e-headers-mark-for-something. What I expect is that mu4e marks all lines that are shown as marked from transient-mark-mode.

Actual behavior

Sometimes this works as expected (all lines shown marked by transient-mark-mode are marked by mu4e) while other times they're applied to all of those lines and to the line point is on, too, even if point is at the beginning of the line. This behavior depends on how I moved point last before using mu4e-headers-mark-for-something.

Steps to reproduce

1. Install mu 1.4.4
2. Run Emacs
3. Turn on transient-mark-mode

Now two different use cases:

1. Open a header view of a maildir containing a couple of messages.
2. Go to the first message/to point-min.
3. Press C-SPC.
4. Press C-n two times.
5. Observe that due to transient-mark-mode the first two lines appear marked.
6. Press *.
7. Observe that mu4e marks the first three lines (= the two appearing marked and the one point is on).

Now a slightly different test:

1. Open a header view of a maildir containing a couple of messages.
2. Go to the first message/to point-min.
3. Press C-SPC.
4. Press C-n three times.
5. Press C-p once.
6. Observe that due to transient-mark-mode the first two lines appear marked, just like in the example above.
7. Press *.
8. Observe that mu4e marks the first two lines only (= only to the two appearing marked from transient-mark-mode), even though point is exactly where it was in the example above.

Versions of mu, mu4e/emacs, operating system etc.

mu 1.4.4 release with corresponding mu4e

Any other detail

My expectation is that both use cases work like the second example as that's how other functions working on regions work (everything up to but excluding point). If that isn't possible, I'd at least expect both cases to work the same way as they look exactly the same from the user's PoV.

This has been happening for as long as I can remember, and it seriously bugs me, having to keep state in my head about how I moved point last wrt. to which messages I want actions applied.

[djcb]

Can't reproduce... both cases yield the same: first two lines are marked and nothing else.

[mbunkus]

Thanks for looking into it so quickly. I'll try to track down which parts of my configuration cause this behavior & report back. Please give me a couple of days.

[mbunkus]

I've been trying to get to a state where it doesn't happen. So what I have now is a minimal init file with which I can open my existing mail store and a short video that shows what I'm doing.

Here's my debug-init.el:

(custom-set-variables
 '(mu4e-drafts-folder "/zz/drafts")
 '(mu4e-get-mail-command "/bin/true")
 '(mu4e-maildir "~/Mail")
 '(mu4e-sent-folder "/bu/sent")
 '(mu4e-trash-folder "/zz/trash")
)

(add-to-list 'load-path "/usr/share/emacs/site-lisp/mu4e")

(require 'mu4e)

Here's how I start Emacs without ANY init file except for the one above:

/usr/bin/emacs -Q -q -nw --load ~/.emacs.d/debug-init.el

Both can be seen in the following video:

https://www.bunkus.org/misc/djcb-mu-issue-1682-1.webm

If you still cannot reproduce it by following these steps, I'm a bit out of ideas what to try next. Do you have anything you'd like me to try? Or anything I might look into?

[djcb]

I tried this again, with a minimal setup, slightly different:

(custom-set-variables
 '(mu4e-drafts-folder "/drafts")
 '(mu4e-get-mail-command "/bin/true")
 '(mu4e-maildir "~/Maildir")
 '(mu4e-mu-binary "/home/djcb/Sources/mu/build/mu/mu")
 )

(add-to-list 'load-path "/home/djcb/Sources/mu/build/mu4e")
(require 'mu4e)

This is with emacs 29 / latest mu4e etc, though I don't know what changed this area. So I'll close this now, hope it's fixed for you too. If you still see it... we can re-open of course, but I don't know what else to do!

[mbunkus]

I've also just upgraded to 29.1 & the latest mu4e, and the problem's gone on my end, too. Great!