[Top][All Lists]

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

Re: Changes for emacs 28

From: Ergus
Subject: Re: Changes for emacs 28
Date: Fri, 11 Sep 2020 15:23:00 +0200

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:


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

reply via email to

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