On Sun, May 24 2020, stardiviner wrote:
Bastien <b...@gnu.org> writes:
C-TAB in Org is bound to `org-force-cycle-archived' to allow to
cycle
through archived subtrees.
In the Emacs tab-bar mode, it is now bound to `tab-next', which
needs
to work globally.
So Org's binding and tab-bar's one are in conflict, as reported
here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41325
I suggest binding `org-force-cycle-archived' to C-M-TAB: any
objection?
Thanks,
I object this change. Emacs tab-bar is not enabled by default.
When conflict,
user can customize keybinding. I don't think it's very necessary
to change.
I would support the change, since both Org mode and tab-bar-mode
are part of core Emacs and I doubt it'll be clear to new users
coming to Emacs why these conflicting key bindings exist. Instead,
they'll be annoyed that they cannot C-TAB out of the Org buffer
and their impression of Emacs (not just Org mode or tab-bar-mode)
will suffer. Ever more so because it's probably not immediately
obvious to new users how C-TAB is different from just TAB: they
both open the subtree at point.
I've been using C-TAB for a long time to switch buffers (albeit
not with tab-bar-mode), and it's always annoying when some mode
usurps (from my perspective) this keybinding. Now, I'm familiar
with Emacs and the relative independence and freedom that
individual packages have, plus C-TAB is a personal keybinding, so
I know this sort of thing may happen and I know how to resolve it.
For a new user, that won't be so obvious. For them, this will
simply look like a badly designed UI.
So I think the general argument for habit-breaking UI changes
applies: it creates a more consistent UI, which means it's easier
on new users and more in line with what they expect. For existing
users that want the old behaviour back, it's a simple
configuration in their init.el.
--
Joost Kremers
Life has its moments
