emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Survey: Toolbars


From: Christopher Dimech
Subject: Re: Emacs Survey: Toolbars
Date: Wed, 16 Dec 2020 17:54:12 +0100


---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Wednesday, December 16, 2020 at 5:03 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Wed, 16 Dec 2020 10:24:07 +0100
> > Cc: emacs-devel@gnu.org
> >
> > I mean, look at the toolbar that happens when you "emacs -Q": You get an
> > Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> > can't be saved.
>
> Which is why the "Save" button is disabled when you are in *scratch*.
>
> > That's how much attention we've spent on toolbars in two decades.
>
> I think we gave the tool bar (and the menu bar) attention it deserves.

There are more important areas for improvement than whether a switch is "on" or 
"off".
For instance, making auto-complete be part of standard emacs by default, 
extending the
completion interface to provide an environment for users to concentrate more on 
their
own work.

Emacs got momentum in the past because of great tools like org-mode, magit, ivy.

> > All the items in the *scratch* buffer toolbar are more natural for a
> > menu, and they're already present there.
>
> That is generally true for any tool bar in any GUI program.
>
>



reply via email to

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