[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "modern" colors Re: Changes for emacs 28

From: Ergus
Subject: Re: "modern" colors Re: Changes for emacs 28
Date: Mon, 14 Sep 2020 11:46:00 +0200

On Mon, Sep 14, 2020 at 11:08:44AM +0300, Göktuğ Kayaalp wrote:
On 2020-09-14 06:50 +03, Richard Stallman <rms@gnu.org> wrote:
  > IMHO this is not really necessary.  A simpler approach would be to
  > simply have a mode which has the plain right click (mouse-3) show a
  > simple menu

Do you mean, this menu is the same regardless of modes, buttons, etc?

The C-Mouse-3 menus offer commands useful for the text you are using.
Why not include that too?

I’d expect that this ‘right click menu’ to have a large skeleton that’s
the same everywhere, but possibly with some salient context relevant
items.  Because that’s what I’ve observed in most operating systems and
GUI applications.  The only place I’ve seen something like Emacs’
C-mouse bindings is NextStep and GnuStep.

Another thing is mouse bindings with modifiers are rather uncommon in
other software.  Personally, the only place I used them was TVM menus.

The current binding of C-mouse-3 is basically the global menu and it’s
way to crowded to be useful as a quick access right click menu.  Ideally
the majority of actions in such a menu would be accessible without
opening submenus.  Otherwise I don’t think providing the global menu at
three different places is of any use.

IMO it is better to improve that same C-mouse-3 and promote it to


A positive side effect would be that this mostly one-level menu would
list some common keybindings like for kill, save kill, yank, M-x, etc.,
so it’d have some didactic value as well.

Totally agree

An interesting way to set things up could be to somehow have a hook
which major modes could use to add a submenu to this right click context
menu, in whatever fashion they see fit.

We do something similar in the menu-bar right? I mean, dynamically add
entries to the menu bar.

The only thing I concern about this is that many modes could try to add
many entries and we end with a bad very long problematic panel. I face
that problem frequently in lxde.

IMHO if we fix the menu I wrote and add the functionality I just
mentioned, we’d have something to play with and modify up until we
eventually arrive at the 28 release cycle, and at that point we’d have
developed an implementation that pleases everyone.

In fact we could just throw a bunch of stuff this whole discussion talks
about behind a configure flag like --with/without-breaking-ui-changes,
and folks like me who use up-to-date builds of Emacs master could
periodically try these out and report breakage, workarounds, usage
patterns, etcetera.  So we’d have an iterative, interactive approach,
rather than trying to ossify everything right at the start.  Actually,
given the size of this discussion, having a separate
‘emacs-modernization’ mailing list could be a good idea too.  Because
this discussion will likely have the spotlight for some certain and long
amount of time up until when 28 becomes ready for release candidates.

If it sounds interesting / plausible, I can post this last paragraph,
with a bit more detail, as it’s own toplevel thread.

İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

reply via email to

[Prev in Thread] Current Thread [Next in Thread]