emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Survey: Toolbars


From: Dmitry Gutov
Subject: Re: Emacs Survey: Toolbars
Date: Thu, 17 Dec 2020 14:08:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 17.12.2020 12:58, Lars Ingebrigtsen wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:

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.  That's how much attention we've spent on toolbars in
two decades.

Well, it actually can be saved, as soon as you type something (C-x C-s
works), and it's one of the real usage patterns. The button doesn't
indicate that, though.

Yeah, the save button stays grayed out and you can't click it, which I
take to be an indication that this toolbar hasn't gotten a lot of love.

It's not obvious how to fix it, though, because an active "save" button is like a reminder to save regularly, whereas saving the scratch is an explicit, advanced usage pattern.

I mean, it's the toolbar shown in "emacs -Q", and even that one is
pretty nonsensical.

I guess I was somewhat attached to the idea of it because it looks pretty and neat on my system (with -Q).

Definitely more so than the splash screen, the discussions about improving which have all seemingly fizzled out.

Maybe you're right. I checked back, and most contemporary text editors
don't have a toolbar like we do.

Atom/Sublime/VS Code don't have this kind of editor toolbar. IDEA only
has specialized toolbars for, like, debugging.

The recent versions of Kate (KDE editor) also seem to have removed
it. GNOME Builder only has a small number of buttons, and they are on
the title bar. Geany still has a toolbar, though.

Even MS Word, while it has a toolbar for certain features, has moved
the basic edit buttons to the window titlebar and made them pretty
small.

I think we should consider setting some standards for what should be in
a toolbar, and normal editing commands shouldn't be there.  That is, a
toolbar should be for things that people want to click a lot, like
"pause" in a media player, or navigation commands like "prev/next" in
*Help*.

Yes, probably. And if there are not enough of such buttons that we can come up with, the toolbar should be hidden for that particular mode.

But... can it work well? Showing the toolbar in some modes yet hiding it in others? Jumping window heights are a known source of annoyance.

All the editors I mentioned above that do have toolbars have avoided this problem, some way or another.



reply via email to

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