Re: Changes for emacs 28

[Arthur Miller]

Ergus <spacibba@aol.com> writes:

> 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)
I also agree, some few years ago before I switched to Helm on "full-time
basis" I used context menus a lot. I had menu-bar and tool-bar turned
off and used mouse to switch buffers and so on. Nowadays it is all Helm
for me since it is even faster to fuzzy complete with a shortcut key
than to move hand to the mouse for the context menu.

There is  a commercial package called Maya. They have a pop-up
window/menu widget they call "hot box". In that pop-up they have all, or
as few as chosen by the user, menus collected in a transparent window
they pop-up under the mouse after the spacebar is hold for a while (I
think it was half a second). As info, the application itself could be
called "emacs for 3d modellers"; it is completely scriptable/extensible
(in-house dialect of TCL), all gui elements can be turned off/on etc.
You can see a demo in action:

https://www.youtube.com/watch?v=o2FB6UIK1rc

(sorry for the YT and non-free JS but it is what it is).

Maybe such or similar widget could be good to have in Emacs? As a
compromise between a minimal GUI, discoverability and avialability of
menus even when gui elements are disabled? A context menu would still be
faster though.