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

Re: Toolbar and info mode (and others)

> > Many major modes add their own menus to the menubar.  Just as it would
> > not be a good idea for them to wipe out the whole menubar, it is not a
> > good idea for major modes to wipe out the toolbar.  After all, the
> > user might want to use some other menu items.  Similarly, the user may
> > want to use some other toolbar buttons.  So, for example, just because
> > I read an Info file, I do not want other toolbar buttons to be
> > unavailable.  If a major mode wants to modify the toolbar, it should
> > *add* to it, without wiping the existing buttons out.

If we're talking about the proverbial Emacs newbie, there are few
things more confusing than wiping out the toolbar ("Where did the
buttons go?").  If the newbie is a heavy toolbar user (which she's
bound to be at first, before she learns using keybindings), this
behavior will be unexpected and disorienting.  In contrast, modifying
the toolbar by appending buttons to it is handy and easy to understand
(not to mention that it suggests, correctly, that major modes *extend*
Emacs's functionality).
> 1. There's not enough space (at least if the frame is 80 columns wide)
>    to add buttons without removing others.  At least with my settings,
>    there no room for any additional button on the standard tool bar.

On modern graphical displays, this is a non-issue.  On my standard
laptop display, if the frame is appr. 80 columns wide, 20-25 buttons
can be placed on the toolbar (i.e., all the standard and Info buttons
would be visible); if the frame is maximized, you could have many
more.  And at least Gtk Emacs does the right thing if there are two
many buttons by placing a button on the right edge which pops up the
toolbar buttons that couldn't fit.

Talking about confusing: the button that resembles an `x' runs
kill-this-buffer on the global toolbar; the same button runs Info-exit
in Info mode.  The former kills the buffer, the latter merely buries
it.  The same button behaves in inconsistently different ways in
different contexts.  You thought you removed Info from the buffer
list, and then it shows up unexpectedly as you move around your

> 2. The tool bar should only contain buttons for the most important
>    commands.  If too many buttons are present, it might be less
>    helpful / confusing.

Modern word processors/text editors often have two or three toolbar
lines with dozens of buttons.  If users don't find this confusing
there, why would they find it confusing in Emacs?  A more extensive
toolbar could help newbies learn/explore Emacs faster.

> 3. Which buttons from the standard tool bar would be very useful in
>    the info mode tool bar (or other major modes) as well?  Please give
>    concrete examples rather than general statements like "other
>    toolbar buttons".  At least <save-buffer>, <write-file>, <undo>,
>    <cut>, <paste> are neither important nor useful (IMHO) in info
>    mode.

What about find-file, dired, copy, print, customize?  You are reading
an Info file which mentions a file/library; you want find it with
dired, or open it, or copy text from the Info buffer, or print your
buffer, or open customize to implement the options you've just read
about, etc., etc.  It is very easy to disable/remove a particular
button which is irrelevant in a context; this happens with the save
button when you have a read-only buffer.

I don't want to sound obnoxious about this issue, and perhaps the
buglist is not the right place to discuss it.  But I know many people
who know a bit about Emacs, think it is great software, but don't use
it because of its steep learning curve.  In my view, a well-designed
toolbar and menubar can help people to climb that curve faster.  There
are also users who have their own ideas about the uses of the toolbar
and write their own, only to find that some modes, including Info,
will wipe it out.


Reply to: