emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: Toolbar and info mode (and others)


From: Reiner Steib
Subject: Re: Toolbar and info mode (and others)
Date: Sun, 25 Mar 2007 23:20:09 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (gnu/linux)

On Sun, Mar 25 2007, Greg Bognar wrote:

> 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?").  

I don't recall a single complaint or bug-report about this (before
yours). Note that info already behaves like this since Emacs 21.

> 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).

Appending makes no sense, see below.

>> 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); 

You should be aware that other users use different settings than
yours.  On mine, only the 14 standard icons fit in one column:

PNG image

> 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.

I know.  But with the default X11 toolkit, a new row is opened, IIRC
(I don't have an Emacs 22 with X11 toolkit available).

> 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
> buffers.

Agreed.  We could use "exit.xpm" instead.

>> 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?  

Are you thinking of badly designed interfaces like M$ Word?  Uses find
this confusing, I think.  No thanks, we don't need to follow bad
paragons.  Look at Firefox or Thunderbird for more carefully designed
tool bars.

> A more extensive toolbar could help newbies learn/explore Emacs
> faster.

I disagree.

>> 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, 

(I myself won't use the tool bar for these commands).  The user could
press <tool-bar> <Exit> (Info-exit) and use the icons from there.  Or
use the menu, or M-x or ...

> print, 

Printing formated info file doesn't make much sense.  Use the
DVI-/PostScript-/PDF-output file for this.

> customize?  

After the release of Emacs 22, we could think about buttonizing
variables (like Gnus does it in article buffers).  I.e. in the
following text, "gnus-select-method" would be a button and pressing it
would end up in the corresponding customize buffer.

,----[ (info "(gnus)Finding the News") ]
| The `gnus-select-method' variable says where Gnus should look for news.
| This variable should be a list where the first element says "how" and
| the second element says "where".  This method is your native method.
| All groups not fetched with this method are foreign groups.
| 
|    For instance, if the `news.somewhere.edu' NNTP server is where you
| want to get your daily dosage of news from, you'd say:
`----

> You are reading an Info file which mentions a file/library; you want
> find it with dired, or open it,

Same here, @file{foo.el} could be represented as link/button.

> 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.

It is not invisible (i.e. room for other icons), but inactive.

> 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.  

We agree on the goal but not on the way, I think.

> 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.

At the current stage (no easy way to customize the tool bar - except
in Gnus ;-)), I think that people who modify the tool bar should be
able to find out how to do this in info mode as well.

>From your initial message:
> 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.

In fact there are some modes that remove some top-level menus.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

reply via email to

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