Skip to content

Conversation

RyanGibb
Copy link
Contributor

@RyanGibb RyanGibb commented Apr 4, 2025

mu4e-search-query was introduced in mu4e v1.12.0:

  • New command mu4e-search-query (bound to =c=) which lets you pick a query (from bookmark / maildir shortcuts) with completion in main / headers / view buffers.

Bindings are added for the main and headers view.

Upstream binds c to mu4e-search-query, and we follow every other binding on the main screen, so we drop the colliding cc binding

See #844, and #860.

mu4e-search-query was introduced in mu4e v1.12.0:
- New command ~mu4e-search-query~ (bound to =c=) which lets you pick a query
  (from bookmark / maildir shortcuts) with completion in main / headers /
  view buffers.

Bindings are added for the main and headers view.

Upstream binds c to mu4e-search-query, and we follow every other binding on the
main screen, so we drop the colliding cc binding
@LoganBarnett
Copy link
Contributor

@RyanGibb doesn't this have the same problem in that we have the other prefixes for things like c e (compose-edit), c r (compose-reply), etc? We'd have to push for those alternative keybindings as well.

IMO it's kind of a step back - I liken compose to magit's commit. I hit c and if I want to do the default thing (just make a new message), I hit c again. But for the compose alternatives I can see those via which-key. That said, my opinion doesn't mean much, and I would indeed mean retaining a deviation from mu4e's default bindings.

I can always override back to the old behavior, and make mu4e-search-query something I can remember (maybe like Q or S). So this isn't terribly a big deal to me :)

@RyanGibb
Copy link
Contributor Author

RyanGibb commented Apr 4, 2025

Hmm, that's a good point. What if we bound C to mu4e-search-query?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants