Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:50:24PM +0300, Dmitry Gutov wrote:
> On 11.09.2020 14:00, Arthur Miller wrote:
> > Dmitry Gutov <dgutov@yandex.ru> writes:
> >
> > > On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
> > > > I'm not a maintainer, but FWIW my opinion is that what will most likely happen
> > > > is that they will never agree to do this.� Menus are not "modern".
> > >
> > > That's certainly the current trend in Emacs customizations, but it's not a
> > > universal rule.
> > >
> > > VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
> > > of course have them too.
> > When I used to make money by programming VBA with MS Office and C++ with
> > VStudio I used to turn off all toolbars and menus I could. Back then
> > computer screens where much smaller then today, and even today I still
> > fight for vertical screen estate on my computer.
>
> I do too. But menus should be helpful for newcomers (and when they are 
> not, we should improve them). So having "starter kits" disable the 
> menus right away seems counter-productive.
>
> BTW, the Unity DE and Sublime Text editor included an alternative UI 
> for menus, where you hit a key (Alt, in the case of Unity) and then 
> fuzzy match on command description.
Just a question as I don't use sublime anymore. Do you mean something
like "autohiding" the toolbar or part of it?

> > For that reason, on my home computer I run a WM without decorations, Emacs
> > without any gui elements more then main gui window, Firefox & Gimp with
> > menus and gui hidden etc. I have never used IntellliJ software, but I
> > guess they will give you option to maximize the working area by
> > disabling the gui items too.
> >
> > Anyway, I don't think GUI should be disabled by default; that should be left to
> > the user. I am really curious which distro you run :-)?
>
> I use Ubuntu with GNOME and the Unite extension which emulates Unity 
> to the best extent possible. That means removing application title 
> bars when the app is maximized, moving their contents (such as menus) 
> to the top panel when possible.
>
> So it's the kind of changes as you did, but to a smaller extent.
The toolbar is less useful if the right click offers the expected
options in a panel (copy, paste, cut, select all, upcase, highlight all
like this, show error at point).

That's why many applications have removed or hided the toolbar; because
a right click is usually faster than moving the mouse to the top of the
screen. (they also use the <menu> key to show the right click panel from
keyboard but we use it for execute-extended-command)

Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
useful at all, but maybe somebody will complain if we change it to
C-<mouse-3> and move the panel to <mouse-3>. Also our right click panel
does not offer those options so it is not as useful now.

Actually there is an external package for that:

https://github.com/zonuexe/right-click-context

So the implementation seems to be pretty simple if we agree in this. WDYT?