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

[Göktuğ Kayaalp]

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.

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.

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.

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