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

[Ergus]

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
mouse-3.

https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01141.html

> 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