Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> From: Terje Bless <link@pobox.com>
> Date: Sat, 20 Apr 2002 13:03:10 +0200
> 
> I've been using XEmacs for programming since the early nineties. I _still_
> have no clue how to switch between buffers from the keyboard!

Is this complaint about the documentation or about the functionality?

While the docs might have this in some non-evident place (although it
isn't in GNU Emacs, and I'd be surprised if it was any different in
XEmacs), the functionality is _certainly_ there: type "C-x b" and
follow the prompts.

> And speaking of which, the thing that confused me most over the years was
> the terminology. A "buffer" is a "document" and a "frame" is a "window"?
> Why do I have to choose "New Frame" when what I /really/ want is a new
> window? And I don't work with "buffers"; I work with "files" or
> "documents". "Buffers" are something hardware /has/ or that I implement in
> code, it's not something I work with day-to-day.

There's a Glossary in the manual to ease the culture shock.  I think
we should advertise the glossary more, and perhaps make it more
accessible by providing special links to it from doc strings etc.

I don't think it's reasonable to expect Emacs to change its
terminology because most of it predates the one you are accustomed to.
For example, Emacs was talking about windows when glass teletype
displays were the only ones in existence.

As for buffers, I disagree that it's unused in the context used by
Emacs.  I've seen several editors that do the same.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Serge Wroclawski]

On Sat, 20 Apr 2002, Terje Bless wrote:

> I've been using XEmacs for programming since the early nineties. I _still_
> have no clue how to switch between buffers from the keyboard! I keep going
> to the Buffers menu and selecting the one I want. In my "other editor" --
> BBEdit on Mac OS X; solidly planted in GUI land -- I /can/ switch between
> buffers from the keyboard.

> Odd that, considering how "keyboard-oriented" XEmacs is, and how "GUI
> oriented" BBEdit is...
>
>
> And speaking of which, the thing that confused me most over the years was
> the terminology. A "buffer" is a "document" and a "frame" is a "window"?
> Why do I have to choose "New Frame" when what I /really/ want is a new
> window? And I don't work with "buffers"; I work with "files" or
> "documents". "Buffers" are something hardware /has/ or that I implement in
> code, it's not something I work with day-to-day.

This issue, while flamable is not entirely bad.

I think a main issue which both the Emacsen have tried to deal with is how
to map the older Emacs terminology onto the common terminology of today.

Buffer is a bad term only becuase it relates to little for the user. Is a
buffer a document? A peice of text? A "window of text".

But it pales in comparison to issues like yank, kill, faces and so on.

Emacs, had it been designed more recently, would have both been aided and
limited by the ideas that permiate today (some which of course some from
editors like Emacs).

The issue is that people see these issues as very important. They want to
think that a yank is not a paste, , a kill is not a cut and a window is
not a frame (and so on). It's mostly true, but thinking that such issues
don't make for a easy use for the new user.

The advantage of GUI Emacsen is that they've covered these issues up by
hiding them. In some cases, they completely hide the issues by replacing
the terms.

If I could make one magic wish for Emacs, it would be that it would
integrate with the Bonobos or similar type functionality of GNOME, that
is, wouldn't it be nice if I could have an Emacs buffer as part of other
applications or that Emacs buffers could "pretend" to be other things more
simply than they can now.

A few examples:

A user wants a terminal emulator. It's possible they'll use the shell
mode. But maybe they like the way the application handles a few things
more than Emacs does and for some good reasons, the Emacs should not do
that (for instance menu placement, language, tabbing).

But there's no reason I can see that the program couldn't call up a way to
access an Emacs buffer and have the Emacs buffer do the hard work.

That is what I see is the biggest thing Emacs needs. Instead of focusing
it efforts on an appealing UI, it needs to make a way for other
applications to work with it, accessing the powerful conceptual aspects of
Emacs while not being as limited by UI decisions which often have no
choice in how they're made.

- Serge Wroclawski

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Terje Bless <link@pobox.com> writes:

> Brady Montz <bradym@balestra.org> wrote:
> 
> >3. we have a nice set of tools for managing which files/buffers you
> >have open and how to switch between them: ibuffer, iswitchb, various
> >things like desktop.el, speedbar, buffer-menu, ...
> 
> I've been using XEmacs for programming since the early nineties. I _still_
> have no clue how to switch between buffers from the keyboard! I keep going
> to the Buffers menu and selecting the one I want. In my "other editor" --
> BBEdit on Mac OS X; solidly planted in GUI land -- I /can/ switch between
> buffers from the keyboard.

iswitchb!!! Use it, live it, love it. 

Comes standard with the latest xemacs I believe.

Since it came out, I've seen some packages which do similar things,
but I'm happily sticking with iswitchb.

As they say - "Emacs has a mode which will write your thesis for
you. Unfortunately, it'll take you 6 years to find it."

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Matt Tucker]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

-- Brady Montz <bradym@balestra.org> spake thusly:

> Terje Bless <link@pobox.com> writes:
> 
>> Brady Montz <bradym@balestra.org> wrote:
>> 
>> I've been using XEmacs for programming since the early nineties. I
>> _still_ have no clue how to switch between buffers from the
>> keyboard! I keep going to the Buffers menu and selecting the one I
>> want. In my "other editor" -- BBEdit on Mac OS X; solidly planted in
>> GUI land -- I /can/ switch between buffers from the keyboard.
> 
> iswitchb!!! Use it, live it, love it. 
> 
> Comes standard with the latest xemacs I believe.
> 
> Since it came out, I've seen some packages which do similar things,
> but I'm happily sticking with iswitchb.

Definitely. Just put:

    (iswitchb-default-keybindings)

in your .emacs, and Use "C-x b" to switch modes. It roxors. :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> As for buffers, I disagree that it's unused in the context used by
> Emacs.  I've seen several editors that do the same.

And anyway, buffers are _not_ the same as `files' or `documents', and
indeed, the name quite accurately describes what it does (and
corresponds directly to the concept of a buffer you say you're used to
doing OS work).  Sometimes there's a one-to-one correspondence between
buffers and files, but quite often there's not.  Once a user learns
about this, he can use this advantage.

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Simon Josefsson]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> From: Terje Bless <link@pobox.com>
>> Date: Sat, 20 Apr 2002 13:03:10 +0200
>> 
>> I've been using XEmacs for programming since the early nineties. I _still_
>> have no clue how to switch between buffers from the keyboard!
>
> Is this complaint about the documentation or about the functionality?

To make people learn the bindings, it could be useful if selecting
stuff from menus left a message in the minibuffer explaining the key
binding.  E.g., selecting something from the Buffers menu could result
in a message "You can also use C-x b to switch buffers".  (Buffers
might not be the best example since selecting a buffer from the menu
isn't exactly the same as using C-x b, but I'm sure there are other
examples that map better.)  I think something similar exists if you
type a M-x command which is bound in the current mode?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> From: Simon Josefsson <jas@extundo.com>
> Date: Sat, 20 Apr 2002 16:04:56 +0200
> 
> To make people learn the bindings, it could be useful if selecting
> stuff from menus left a message in the minibuffer explaining the key
> binding.

The menu itself shows the keybinding, if any, that invokes the same
command.  Isn't that good enough?  AFAIK, this is the accepted way of
showing keyboard equivalents of menu commands in other GUI
applications.

> I think something similar exists if you type a M-x command which is
> bound in the current mode?

Yes; see the suggest-key-binding variable.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andreas Schwab]

Simon Josefsson <jas@extundo.com> writes:

|> To make people learn the bindings, it could be useful if selecting
|> stuff from menus left a message in the minibuffer explaining the key
|> binding.

The key bindings are already shown in the menu entries.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Eli Zaretskii <eliz@fencepost.gnu.org> writes:

> The menu itself shows the keybinding, if any, that invokes the same
> command.  Isn't that good enough?

It's not good enough for what Terje was complaining about.  Under
XEmacs, if you open the "Buffers" menu, you can choose the buffer you
want to go to.  But there is no keybinding equivalent to "go to buffer
named foo.c", hence none is written.  In this case, one must learn the
procedure by reading the manual.  I have no problem with this, but
Terje confesses to have been unwilling to do so for years.  Maybe it
can be improved?

>> I think something similar exists if you type a M-x command which is
>> bound in the current mode?
>
> Yes; see the suggest-key-binding variable.

Since this is cross-posted to XEmacs lists, the variable name is
`teach-extended-commands-p' under XEmacs.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Hrvoje Niksic <hniksic@arsdigita.com> wrote:

>Eli Zaretskii <eliz@fencepost.gnu.org> writes:
>
>>The menu itself shows the keybinding, if any, that invokes the same
>>command.  Isn't that good enough?
>
>It's not good enough for what Terje was complaining about.  Under
>XEmacs, if you open the "Buffers" menu, you can choose the buffer you
>want to go to.  But there is no keybinding equivalent to "go to buffer
>named foo.c", hence none is written.

Actually, it's slightly worse. I use

  '(buffers-menu-submenus-for-groups-p t)

(I have no idea what this feature is /really/ called)

and the "Switch to Buffer" command in the buffer sub-menu lists no keyboard
shortcut. None of the menus offer a way to cycle sequentially through
buffers and certainly offer no keyboard equivalent. The lack of a command
to go to a named buffer is irrelevant; doing that involves so much typing
I'd rather select it from the menu.


>In this case, one must learn the procedure by reading the manual.  I
>have no problem with this, but Terje confesses to have been unwilling
>to do so for years.  Maybe it can be improved?

Well, from my point of view, it certainly can. As we discussed some years
ago Hrvoje, from my point of view (X)Emacs is a mere editor; a tool for
editing the kinds of files that I want to edit. The fact that it has a lisp
interpreter and a rich library isn't an advantage; it's a _liability_. I
don't know lisp. I don't even /like/ lisp. I do like a specific subset of
Emacs-the-text-editor's features though.

So to improve the "manual" for /me/ you'd have to remove every reference to
lisp from it. Feel free to explain the concepts Emacs uses and mention that
.emacs contains "configuration", but the second you throw in a "sexp" or a
"feature-p" or too many parens you've lost me.

I'll freely and gladly admit to ignorance, to inability to learn, and to
these being my failures and not Emacs´. But wouldn't it be nice if Emacs
could make up for my failings so that I could be productive with it too?

I get by with C-x C-f, C-x C-s, C-s, and C-x C-c. I manage the occasional
foray into Customize and instructions that say "put this in your .emacs".
And the stuff in the Options menu makes my life ever so much easier.

But a lot of the time I'm hindered by the fact that Emacs insists on me
adapting to it, instead of it adapting to me. It "DWIMs" fairly well in
some situations, but a lot less well in others. And writing lisp code is
considered an acceptable way to interact with Emacs for normal users!



But the real point of all this isn't any specific feature or implementation
detail. The main point I'd like to make is that, again in my opinion, the
single most important factor in making Emacs more accessible to more people
is to start giving more weight to these issues (and, yes, as a consequence
less weigth to other issues; it's a tradeoff when resources are limited).

The technical merit of any given feature is important. The cleanliness of
it's API, or of how it uses the API, is important. How powerfull the
feature is, how fast it is, how much overhead it has, these are all
important issues. But how well it fits in with the expectations of Joe R.
User is _also_ important!

The perfect feature needs no documentation because it's intuitively obvious
how it works. It's existence so obvious that it doesn't need to be pointed
out, and it's placement so natural that the user doesn't have to be pointed
in the right direction. That's not achievable of course, but striving to
approach that (to the point where diminishing returns dictates you stop)
will be _better_ even if perfection is not possible.


Or maybe I just wish to redefine what is the "average" user of Emacs.

Right now, as far as I can tell, the "average" user knows more then average
(if you'll pardon the pun) about lisp and the implementation details of
Emacs. There is a fairly large barrier to entry. When you pass it it will
scale upwards very well, but it doesn't scale _down_ at all well. There is
this huge gap between doing everything from the menus and writing your own
custom lisp bits to make Emacs behave the way you want it to.

This gap is what I first would like to see filled. But there is also a
possibility that Emacs just isn't the tool for me. Perhaps it's too
advanced a tool for my simple use and I should stay with less powerfull,
but also more easy to understand tools. That's a valid point of view. I'd
like to see Emacs cater to me also, and I firmly believe it can do that
without compromising away the power it has that more advanced users need.


Oh, one final thing... I usually keep my mouth shut on these lists. I lurk
here because I like to keep tabs on what's happening in the future for my
toolchain and because they're sometimes informative and sometimes funny
(the recent threads on garbage collectors on Xemacs-beta fall into both
categories ;D). I'm poking my nose in here because I genuinely believe that
my point of view might be usefull to those actually designing and
implementing the Emacsen. Anyone that disagrees may feel free to tell me to
buggar off and mind my own business (though perhaps off-list). I promise I
won't be offended! :-)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Hrvoje Niksic <hniksic@arsdigita.com> writes:
> > The menu itself shows the keybinding, if any, that invokes the same
> > command.  Isn't that good enough?
> 
> It's not good enough for what Terje was complaining about.  Under
> XEmacs, if you open the "Buffers" menu, you can choose the buffer you
> want to go to.  But there is no keybinding equivalent to "go to buffer
> named foo.c", hence none is written.  In this case, one must learn the
> procedure by reading the manual.

I think for the Buffer-menu case, it would be enough to add the usual
`Switch to Buffer' command as a special entry.  If, for instance the
menu looked like this:

        +-------------------------------+
        |Buffer 1                       |
        |Buffer 2                       |
        |...                            |
        |-------------------------------|
        |Select Named Buffer   (C-x b)  |
        |List All Buffers      (C-x C-b)|
        +-------------------------------+

Then users would figure it out.  Currently emacs has the `List All
Buffers' command in the Buffers menu, but not `Select Named Buffer'
(I don't know about xemacs).

[Incidentally, there probably should be a separator line between the
buffer names and the commands in that menu -- currently there's not.]

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Miles Bader <miles@gnu.org> writes:

> I think for the Buffer-menu case, it would be enough to add the
> usual `Switch to Buffer' command as a special entry.  If, for
> instance the menu looked like this:
>
>         +-------------------------------+
>         |Buffer 1                       |
>         |Buffer 2                       |
>         |...                            |
>         |-------------------------------|
>         |Select Named Buffer   (C-x b)  |
>         |List All Buffers      (C-x C-b)|
>         +-------------------------------+
>
> Then users would figure it out.  Currently emacs has the `List All
> Buffers' command in the Buffers menu, but not `Select Named Buffer'
> (I don't know about xemacs).

XEmacs already has these commands in the menu, so apparently something
else is required.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Hrvoje Niksic <hniksic@arsdigita.com> writes:
> XEmacs already has these commands in the menu, so apparently something
> else is required.

Well, there _are_ limits -- if someone is familiar with the convention
for showing keybindings in menus (as most people are), and has been
using the Buffers menu to switch buffers for a long time, and yet has
failed to notice a the `Switch to Named Buffer' entry with accompanying
keybinding (and it should be rather hard to miss, since if there are
only two commands with keybindings shown in the menu), then I'm not sure
there's much that can be done for that person.

Are there lots of other keybindings show in the xemacs Buffers menu
that might obscure that entry?

-MIles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Robert J. Chassell]

   ... the `Switch to Named Buffer' entry with accompanying keybinding
   (and it should be rather hard to miss, since if there are only two
   commands with keybindings shown in the menu), ...

I don't know about Xemacs, but in yesterday's CVS snapshot of

    GNU Emacs 21.2.50.107 (i686-pc-linux-gnu, X toolkit) of 2002-04-20

started with

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

the `Buffer' menu item does not show the keyboard command for
switching to a buffer, only the command for `List All Buffers', 
C-x C-b.

The tutorial does not list the `Switch to Named Buffer' keyboard
command, C-x b, either!

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> the `Buffer' menu item does not show the keyboard command for
> switching to a buffer, only the command for `List All Buffers', 
> C-x C-b.

Right, but I believe the person who originally posted is using xemacs.

We should add that command to the Buffers menu though, I think (and a
separator line to separate the buffer-names from commands).

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I don't know about Xemacs, but in yesterday's CVS snapshot of

Hrvoje said that switch-to-buffer _is_ listed in XEmacs, yet that
still doesn't seem to be enough.

kai
-- 
Silence is foo!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Sat, 20 Apr 2002, Hrvoje Niksic wrote:

> Eli Zaretskii <eliz@fencepost.gnu.org> writes:
> 
> > The menu itself shows the keybinding, if any, that invokes the same
> > command.  Isn't that good enough?
> 
> It's not good enough for what Terje was complaining about.  Under
> XEmacs, if you open the "Buffers" menu, you can choose the buffer you
> want to go to.  But there is no keybinding equivalent to "go to buffer
> named foo.c", hence none is written.  In this case, one must learn the
> procedure by reading the manual.

So how about a feature whereby a menu item could specify a related 
command, or a list of commands?  That info could be used by various help 
facilities, like display the commands in the echo area or in a tooltip, 
etc.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Eli Zaretskii wrote:
>>From: Terje Bless <link@pobox.com>
>>Date: Sat, 20 Apr 2002 13:03:10 +0200

>>And speaking of which, the thing that confused me most over the years was
>>the terminology. A "buffer" is a "document" and a "frame" is a "window"?
>>Why do I have to choose "New Frame" when what I /really/ want is a new
>>window? And I don't work with "buffers"; I work with "files" or
>>"documents". "Buffers" are something hardware /has/ or that I implement in
>>code, it's not something I work with day-to-day.
> 
> 
> There's a Glossary in the manual to ease the culture shock.  I think
> we should advertise the glossary more, and perhaps make it more
> accessible by providing special links to it from doc strings etc.
> 
> I don't think it's reasonable to expect Emacs to change its
> terminology because most of it predates the one you are accustomed to.
> For example, Emacs was talking about windows when glass teletype
> displays were the only ones in existence.
> 
> As for buffers, I disagree that it's unused in the context used by
> Emacs.  I've seen several editors that do the same.
> 

I agree with Terje on this.  If XEmacs is to be designed to be more easily 
usable by newbies, the terminology should change along with the interface.

I don't understand your point that "the term window used to mean something 
else"... I mean, if we're going to ignore the new terminology, why don't we 
just call programs 'punch cards', because that's what they used to be?

Changing the terminology would help new users, and I think that old users 
would be able to get used to the changes pretty quickly, since they'd all be 
pretty intuitive (assuming they're just being updated to the terms commonly 
used today).

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kyle Jones]

Michael Toomim writes:
 > Eli Zaretskii wrote:
 > >>From: Terje Bless <link@pobox.com>
 > >>Date: Sat, 20 Apr 2002 13:03:10 +0200
 > 
 > >>And speaking of which, the thing that confused me most over the years was
 > >>the terminology. A "buffer" is a "document" and a "frame" is a "window"?
 > >>Why do I have to choose "New Frame" when what I /really/ want is a new
 > >>window? And I don't work with "buffers"; I work with "files" or
 > >>"documents". "Buffers" are something hardware /has/ or that I implement in
 > >>code, it's not something I work with day-to-day.
 > > 
 > > 
 > > There's a Glossary in the manual to ease the culture shock.  I think
 > > we should advertise the glossary more, and perhaps make it more
 > > accessible by providing special links to it from doc strings etc.
 > > 
 > > I don't think it's reasonable to expect Emacs to change its
 > > terminology because most of it predates the one you are accustomed to.
 > > For example, Emacs was talking about windows when glass teletype
 > > displays were the only ones in existence.
 > > 
 > > As for buffers, I disagree that it's unused in the context used by
 > > Emacs.  I've seen several editors that do the same.
 > > 
 > 
 > I agree with Terje on this.  If XEmacs is to be designed to be more easily 
 > usable by newbies, the terminology should change along with the interface.

What about the confusion this will cause with existing users?
This sounds to me like changing Emacs for the sake of those who
don't like or support it to the detriment of those who do like
and support it, and that is just perverse.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Nix]

On Sat, 20 Apr 2002, Michael Toomim said:
> Changing the terminology would help new users, and I think that old
> users would be able to get used to the changes pretty quickly, since
> they'd all be pretty intuitive (assuming they're just being updated to
> the terms commonly used today).

Bear in mind that the terminology is an API problem too: the terms
`buffer', `window', `frame' and so on are in the Lisp layer of (X)Emacs
and are used by Lisp code.

If we don't change the Lisp layer too, we introduce a serious
inconsistency between the terms used for the user-interface and the
terms used for Lisp (both of which blend seamlessly at present.)

If we do change the Lisp layer, we break the world.

-- 
`Unless they've moved it since I last checked, travelling between
 England and America does not involve crossing the equator.'
   --- pir

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alfred M. Szmidt]

* Michael Toomim writes:
> Changing the terminology would help new users, and I think that old
> users would be able to get used to the changes pretty quickly, since
> they'd all be pretty intuitive (assuming they're just being updated
> to the terms commonly used today).

Seriously, changing the terminology just to help new users is to funny,
if someone wants to learn about the terminology then they should read the
dictionary (it actually exists to be read).  Just because someone doesn't
understand what `esophagus' means, doesn't mean that the word should be
changed to something that is more suitable to new people that are interested
in biology.

-- 
Alfred M. Szmidt

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Kyle Jones <kyle_jones@wonderworks.com> wrote:

>Michael Toomim writes:
>
>>If XEmacs is to be designed to be more easily usable by newbies, the
>>terminology should change along with the interface.
>
>What about the confusion this will cause with existing users? This
>sounds to me like changing Emacs for the sake of those who don't like or
>support it to the detriment of those who do like and support it, and
>that is just perverse.

Yes. That would be a singularily bad idea.

The point shouldn't be to "make newbies feel at home", but rather to make
it _better_. For everyone. The novices are who would benefit the most from
it, but certainly not the only group.




-- 
"Frailty, thy name is woman!"                    - Hamlet, Prince of Denmark.
                   See Project Gutenberg <URL:http://promo.net/pg/> for more.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Kyle Jones wrote:
>  > I agree with Terje on this.  If XEmacs is to be designed to be more easily 
>  > usable by newbies, the terminology should change along with the interface.
> 
> What about the confusion this will cause with existing users?
> This sounds to me like changing Emacs for the sake of those who
> don't like or support it to the detriment of those who do like
> and support it, and that is just perverse.

As was discussed in previous posts, the point isn't to force a new UI onto old 
users, but to provide it as an option -- either a run-time option or a branch. 
  Old users will have the same interface they always had, unless the decide to 
try out the new UI.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Michael Toomim <toomim@cs.berkeley.edu> writes:
> As was discussed in previous posts, the point isn't to force a new UI
> onto old users, but to provide it as an option -- either a run-time
> option or a branch.
> Old users will have the same interface they
> always had, unless the decide to try out the new UI.

Changing such basic terms as `buffer' seems like it could only be done
optionally if it were done at a very superficial level -- e.g., only
menu entries and prompts.

However, this would make things _more_ confusing for users who decide
to move beyond the menus, and try to learn more about emacs' more
advanced features.  For instance, the menu might say `Switch to Document',n
but if they tried out M-x, they'd have to type `Mx-x switch-to-buffer'.

One of emacs' great strengths (in my opinion) is the ease with which you
can move from simple tasks to more advanced ones -- not because there's
a super-easy GUI, but because you can make this move in very small steps
(use menus -> use keybindings -> use M-x -> write simple lisp
expressions to bind keys -> write simple lisp functions -> write
operating systems...).

Any change that makes this appreciably harder seems like a Very Bad Idea.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Alfred M. Szmidt <ams@kemisten.nu> wrote:

>* Michael Toomim writes:
>>Changing the terminology would help new users, and I think that old
>>users would be able to get used to the changes pretty quickly, since
>>they'd all be pretty intuitive (assuming they're just being updated to
>>the terms commonly used today).
>
>Seriously, changing the terminology just to help new users is to funny,
>if someone wants to learn about the terminology then they should read
>the dictionary (it actually exists to be read).  Just because someone
>doesn't understand what `esophagus' means, doesn't mean that the word
>should be changed to something that is more suitable to new people that
>are interested in biology.

This actually makes my point very well.

Since I'm not too find of analogies I won't delve into any long discussion
of jargon among peers vs. popular (or populist) science.

You choose your level of abstraction based on the vocabulary of your
audience. We aren't talking about people interested in "biology" here;
we're talking about a patient seeing a doctor. Talking about the
implementation and demanding familiarity with terminology is fine for
budding Emacs _developers_, but it's (IMO) inappropriate for people who
merely want to /use/ Emacs to perform some task. If my doctor told me I had
an inflamed pharynx I wouldn't know what the hell he was talking about. A
sore throat OTOH is perfectly understandable and is probably accurate
_enough_ under the circumstances.



-- 
>For all I know they probably have a standard for
>which direction to put the thread on a bolt.

That would be ISO 261:1973.         -- John Cowan

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alfred M. Szmidt]

* Terje Bless writes:
> You choose your level of abstraction based on the vocabulary of your
> audience. We aren't talking about people interested in "biology"
> here; we're talking about a patient seeing a doctor. Talking about
> the implementation and demanding familiarity with terminology is
> fine for budding Emacs _developers_, but it's (IMO) inappropriate
> for people who merely want to /use/ Emacs to perform some task. If
> my doctor told me I had an inflamed pharynx I wouldn't know what the
> hell he was talking about. A sore throat OTOH is perfectly
> understandable and is probably accurate _enough_ under the
> circumstances.

Since when do you choose your level of abstraction based on the vocabulary of
your audience? You choose if based on what makes sense.  In our case, a buffer
makes a perfectly good choice for a word, as you are not really opening a file,
you are opening a temporary file, a buffer.  I really don't see what this
has to do with developers, what about people that have just /used/ Emacs since
a decade back? Or people that have /used/ it for a couple of years?  A lot
of old timers would get pretty confused if you change the terminology.  And
the glossary in the Emacs manual is something that new users should read. I
also think that the tutorial describes what a buffer is in words that are
suiting new users.  Instead of changing the terminology why not improve the
definition of it so that it is easier to understand.

-- 
Alfred M. Szmidt

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Alfred M. Szmidt wrote:
> 
> Seriously, changing the terminology just to help new users is to funny,
> if someone wants to learn about the terminology then they should read the
> dictionary (it actually exists to be read).  Just because someone doesn't
> understand what `esophagus' means, doesn't mean that the word should be
> changed to something that is more suitable to new people that are interested
> in biology.
> 

There's a thing called "user-centered design".  In modern times, it is
generally accepted to be good.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alfred M. Szmidt]

* Michael Toomim writes:
> There's a thing called "user-centered design".  In modern times, it
> is generally accepted to be good.

Maybe you should call it "new user-centred design"?  Because it surely doesn't
make any sense on changing the name of such a basic concept like "buffer" to
"document" or "file" when you are already familiar with Emacs.  The whole
terminology is so hard coded into Emacs that it would be a pitta to change,
and would cause more harm than good.  Think of all the old time users, they
would still call buffers for buffers, and new users would ask what a buffer is.

Maybe the entry in the Emacs manual (Glossary) should be fixed to describe
what a buffer is so that it makes more sense to a user, but changing it to
something totally different? No. That would be like rewriting Emacs.

Buffer
     The buffer is the basic editing unit; one buffer corresponds to
     one text being edited.  You can have several buffers, but at any
     time you are editing only one, the `current buffer,' though
     several can be visible when you are using multiple windows (q.v.).
     Most buffers are visiting (q.v.) some file.  *Note Buffers::.

Personally, I think it is pretty clear, do you have any ideas on how one could
improve this?

-- 
Alfred M. Szmidt

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Alfred M. Szmidt <ams@kemisten.nu> wrote:

>* Michael Toomim writes:
>>There's a thing called "user-centered design".  In modern times, it is
>>generally accepted to be good.
>
>Maybe you should call it "new user-centred design"?  Because it surely
>doesn't make any sense on changing the name of such a basic concept like
>"buffer" to "document" or "file" when you are already familiar with
>Emacs.  The whole terminology is so hard coded into Emacs that it would
>be a pitta to change, and would cause more harm than good.  Think of all
>the old time users, they would still call buffers for buffers, and new
>users would ask what a buffer is.
>
>Maybe the entry in the Emacs manual (Glossary) should be fixed to
>describe what a buffer is so that it makes more sense to a user, but
>changing it to something totally different? No. That would be like
>rewriting Emacs.

I think I may have confused the issue rather more then I helped. Sorry.

My (rather ineptly explained) point was rather that good UI design should
focus on the task the user wishes to acomplish instead of how the feature
is implemented. The buffer/file dichotomy was merely an example, and
possibly a poor one at that. The main idea was that when I'm working using
XEmacs I don't think about performing operations on a buffer; I think about
the task as opening a file and editing it. Forcing me to think in terms of
loading data into a buffer, and performing operations on that buffer before
writing it back to disk, imposes an additional cognitive burden on me.

I'm not suggesting you do a global search and replace of "file" for
"buffer"; only that you take this point of view into account when designing
and architecting all aspects of the application. I'm advocating abstracting
the user interface away from the implementation details. This does mean
there is an abstraction between UI and implementation that will be a burden
for those developing it. That may be too expensive a tradeoff for the
developers, but I'd hoped not, as many other developers manage this without
too much pain. Of course, the Emacsen are somewhat unique in this respect.


I do not (not not not!) suggest dumbing down XEmacs! I'm suggesting
_smarting_ it up! That is, provide more friendly and helpfull features for
those that need them while staying out of the way of those that do not.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alfred M. Szmidt]

* Terje Bless writes:
> I do not (not not not!) suggest dumbing down XEmacs! I'm suggesting
> _smarting_ it up! That is, provide more friendly and helpfull
> features for those that need them while staying out of the way of
> those that do not.
Then why change the terminology?  The user gets smarter by reading, like say
reading the Glossary in the Emacs manual.  That way this person who is new
to Emacs will learn things, and become smarter in the process.

-- 
Alfred M. Szmidt

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Robert J. Chassell]

   ... "buffer" to "document" or "file"  ...

Please be careful about language.

Sometimes a buffer is an unsaved document; sometimes it is a saved
document.  There is a big difference.  And sometimes a document is
not online at all, but is printed.

And ..., right now, in another buffer, I am looking at a picture,
I would not call a picture a document, although a picture may be
within a document, but not always.  In this case, the picture is not
within a document.

How about extracting idea from this in your definition of `buffer'?
Thexe excerpts come from Info, File: eintr, Node: Buffer Names

       A file and a buffer are two different entities.  A file is
    information recorded permanently in the computer (unless you
    delete it).  A buffer, on the other hand, is information inside of
    Emacs that will vanish at the end of the editing session (or when
    you kill the buffer).  Usually, a buffer contains information that
    you have copied from a file; we say the buffer is "visiting" that
    file.  This copy is what you work on and modify.  Changes to the
    buffer do not change the file, until you save the buffer.  When
    you save the buffer, the buffer is copied to the file and is thus
    saved permanently.

    ...

       In spite of the distinction between files and buffers, you will
    often find that people refer to a file when they mean a buffer and
    vice-versa.  Indeed, most people say, "I am editing a file,"
    rather than saying, "I am editing a buffer which I will soon save
    to a file."  It is almost always clear from context what people
    mean.  When dealing with computer programs, however, it is
    important to keep the distinction in mind, since the computer is
    not as smart as a person.

       The word `buffer', by the way, comes from the meaning of the
    word as a cushion that deadens the force of a collision.  In early
    computers, a buffer cushioned the interaction between files and
    the computer's central processing unit.  The drums or tapes that
    held a file and the central processing unit were pieces of
    equipment that were very different from each other, working at
    their own speeds, in spurts.  The buffer made it possible for them
    to work together effectively.  Eventually, the buffer grew from
    being an intermediary, a temporary holding place, to being the
    place where work is done.  This transformation is rather like that
    of a small seaport that grew into a great city: once it was merely
    the place where cargo was warehoused temporarily before being
    loaded onto ships; then it became a business and cultural center
    in its own right.

       Not all buffers are associated with files.  For example, when
    you start an Emacs session by typing the command `emacs' alone,
    without naming any files, Emacs will start with the `*scratch*'
    buffer on the screen.  This buffer is not visiting any file.
    Similarly, a `*Help*' buffer is not associated with any file.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alfred M. Szmidt]

* Robert J Chassell writes:
>    ... "buffer" to "document" or "file" ...
> Please be careful about language.

Yes, but the whole discussion is about changing the terminology, i.e. calling
a buffer a file/document, which is wrong, as they are totally different things,
as you nicely noted.

[snip - a nice and long description about buffer vs. file ]

-- 
Alfred M. Szmidt

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Miles Bader wrote:
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
>>As for buffers, I disagree that it's unused in the context used by
>>Emacs.  I've seen several editors that do the same.
> 
> 
> And anyway, buffers are _not_ the same as `files' or `documents', and
> indeed, the name quite accurately describes what it does (and
> corresponds directly to the concept of a buffer you say you're used to
> doing OS work).  Sometimes there's a one-to-one correspondence between
> buffers and files, but quite often there's not.  Once a user learns
> about this, he can use this advantage.

The term "buffer" means nothing to a new emacs user, even if they thoroughly 
understand the dictionary definition of it.

It would make much more sense to new users if they were just called files or 
documents, since that's what they are to newbies, and learning what a buffer 
is is a big hurdle one has to jump over when learning emacs.

Calling them documents or files wouldn't be that bad.  If they don't exist on 
disk, the users can just think of them as "files that haven't been saved yet". 
  Most text editors call these things "documents", and users tend to have no 
problem incorporating the the fact that they might not have been saved into 
their cognitive model of the system.

Then you have to deal with all the *other* buffers... (dired, help, info...) 
Maybe to do this right, one would have to come up with two entirely different 
names for these different types of buffers (sort of a terminology API built on 
top of buffers).  But I think that the term "document" might apply ok to them 
as well in a user interface... I don't think that the slight strangeness would 
be too much of a problem.  Of course, this is all just intuition.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kyle Jones]

Michael Toomim writes:
 > Miles Bader wrote:
 > > "Eli Zaretskii" <eliz@is.elta.co.il> writes:
 > > 
 > >>As for buffers, I disagree that it's unused in the context used by
 > >>Emacs.  I've seen several editors that do the same.
 > > 
 > > 
 > > And anyway, buffers are _not_ the same as `files' or `documents', and
 > > indeed, the name quite accurately describes what it does (and
 > > corresponds directly to the concept of a buffer you say you're used to
 > > doing OS work).  Sometimes there's a one-to-one correspondence between
 > > buffers and files, but quite often there's not.  Once a user learns
 > > about this, he can use this advantage.
 > 
 > The term "buffer" means nothing to a new emacs user, even if
 > they thoroughly understand the dictionary definition of it.
 > 
 > It would make much more sense to new users if they were just
 > called files or documents, since that's what they are to
 > newbies, and learning what a buffer is is a big hurdle one
 > has to jump over when learning emacs.

It's a hurdle that one has to jump with any editor in which you
edit a copy of a file and commit changes only by "saving" them.
If people have trouble with this concept then this is just one of
those things they will have to learn because editing a buffer is
in fact what is happening.  If you don't understand the buffer
concept then you'll wonder why your edits don't take effect in
the filesystem as soon as you type them.  Is their anyone using
computers today who doesn't understand the concept of an edit
buffer, even if they don't know the term "buffer"?  If not, then
it's just a matter of them learning a new word.  People who won't
learn a new word display a breaktaking intellectual bankruptcy
that's far beyond our ability to change.

I know the pain of which you speak.  Recently I've started learning
how to use the Gimp and a lot of the terms (or the way the terms are
used) are new to me.  But that isn't surprising because I don't do
digital image processing for a living.  I don't expect the Gimp's
authors to change their terminology to suit me, an ignoramus.  What
I want is that whatever terms they use be used consistently within
the application so that time spent learning the terms isn't wasted.

That's the goal we should strive for.  We should use terminology
that's familiar to normal practitioners of the art and we should
use it consistently.  This does not mean saying "lepidoptera"
instead of "butterfly", this means saying "butterfly" instead of
"bug".

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

I think the issue is not so much that Emacs uses weird terminology but that
Emacs uses different terminology to a hundred other editors. Seems like
we're arguing for Esperanto rather than words that are actually in the
dictionary.

andy

> -----Original Message-----
> From: xemacs-design-admin@xemacs.org
> [mailto:xemacs-design-admin@xemacs.org]On Behalf Of Kyle Jones
> Sent: Saturday, April 20, 2002 2:27 PM
> To: Michael Toomim
> Cc: Miles Bader; Eli Zaretskii; link@pobox.com; bradym@balestra.org;
> xemacs-design@xemacs.org; emacs-devel@gnu.org
> Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more
> up-to-date)
>
>
> Michael Toomim writes:
>  > Miles Bader wrote:
>  > > "Eli Zaretskii" <eliz@is.elta.co.il> writes:
>  > >
>  > >>As for buffers, I disagree that it's unused in the context used by
>  > >>Emacs.  I've seen several editors that do the same.
>  > >
>  > >
>  > > And anyway, buffers are _not_ the same as `files' or `documents', and
>  > > indeed, the name quite accurately describes what it does (and
>  > > corresponds directly to the concept of a buffer you say
> you're used to
>  > > doing OS work).  Sometimes there's a one-to-one
> correspondence between
>  > > buffers and files, but quite often there's not.  Once a user learns
>  > > about this, he can use this advantage.
>  >
>  > The term "buffer" means nothing to a new emacs user, even if
>  > they thoroughly understand the dictionary definition of it.
>  >
>  > It would make much more sense to new users if they were just
>  > called files or documents, since that's what they are to
>  > newbies, and learning what a buffer is is a big hurdle one
>  > has to jump over when learning emacs.
>
> It's a hurdle that one has to jump with any editor in which you
> edit a copy of a file and commit changes only by "saving" them.
> If people have trouble with this concept then this is just one of
> those things they will have to learn because editing a buffer is
> in fact what is happening.  If you don't understand the buffer
> concept then you'll wonder why your edits don't take effect in
> the filesystem as soon as you type them.  Is their anyone using
> computers today who doesn't understand the concept of an edit
> buffer, even if they don't know the term "buffer"?  If not, then
> it's just a matter of them learning a new word.  People who won't
> learn a new word display a breaktaking intellectual bankruptcy
> that's far beyond our ability to change.
>
> I know the pain of which you speak.  Recently I've started learning
> how to use the Gimp and a lot of the terms (or the way the terms are
> used) are new to me.  But that isn't surprising because I don't do
> digital image processing for a living.  I don't expect the Gimp's
> authors to change their terminology to suit me, an ignoramus.  What
> I want is that whatever terms they use be used consistently within
> the application so that time spent learning the terms isn't wasted.
>
> That's the goal we should strive for.  We should use terminology
> that's familiar to normal practitioners of the art and we should
> use it consistently.  This does not mean saying "lepidoptera"
> instead of "butterfly", this means saying "butterfly" instead of
> "bug".
>

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

On Sat, 2002-04-20 at 14:26, Kyle Jones wrote:
> Michael Toomim writes:
>  > 
>  > The term "buffer" means nothing to a new emacs user, even if
>  > they thoroughly understand the dictionary definition of it.
>  > 
>  > It would make much more sense to new users if they were just
>  > called files or documents, since that's what they are to
>  > newbies, and learning what a buffer is is a big hurdle one
>  > has to jump over when learning emacs.
> 
> It's a hurdle that one has to jump with any editor in which you
> edit a copy of a file and commit changes only by "saving" them.
> If people have trouble with this concept then this is just one of
> those things they will have to learn because editing a buffer is
> in fact what is happening.  If you don't understand the buffer
> concept then you'll wonder why your edits don't take effect in
> the filesystem as soon as you type them.  Is their anyone using
> computers today who doesn't understand the concept of an edit
> buffer, even if they don't know the term "buffer"?  If not, then
> it's just a matter of them learning a new word.  People who won't
> learn a new word display a breaktaking intellectual bankruptcy
> that's far beyond our ability to change.

I think there's been a miscommunication here.  I wasn't saying that
users can't understand the concept of a "document that hasn't been saved
yet".  That is silly.  I was just saying that the word "buffer" doesn't
mean anything to new users, and that by calling their documents
"buffers" they get confused.

Users already understand the *concept* of a buffer just fine.  The
problem is that they use the word "document" for it.

People have all sorts of meaning attached to the word "buffer".  A
buffer is:

1 : any of various devices or pieces of material for reducing shock or
damage due to contact
2 : a means or device used as a cushion against the shock of
fluctuations in business or financial activity
3 : something that serves as a protective barrier: as a : BUFFER STATE b
: a person who shields another especially from annoying routine matters
c : MEDIATOR 1
4 : a substance capable in solution of neutralizing both acids and bases
and thereby maintaining the original acidity or basicity of the
solution; also : a solution containing such a substance
5 : a temporary storage unit (as in a computer); especially : one that
accepts information at one rate and delivers it at another

Basically, it comes down to the problem that a buffer is a system-level
representation -- it is a description a C/lisp data structure.  People
think of these things as documents (just take a look at any mainstream
text editor), so it would help if they were called documents.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Sat, 20 Apr 2002, Michael Toomim wrote:

> The term "buffer" means nothing to a new emacs user, even if they thoroughly 
> understand the dictionary definition of it.

That's why new users should read the tutorial: it explains the basic 
terminology, including "buffer".

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Miles Bader <miles@gnu.org> wrote:

>"Eli Zaretskii" <eliz@is.elta.co.il> writes:
>>As for buffers, I disagree that it's unused in the context used by
>>Emacs.  I've seen several editors that do the same.
>
>And anyway, buffers are _not_ the same as `files' or `documents', and
>indeed, the name quite accurately describes what it does (and
>corresponds directly to the concept of a buffer you say you're used to
>doing OS work).  Sometimes there's a one-to-one correspondence between
>buffers and files, but quite often there's not.  Once a user learns
>about this, he can use this advantage.

This is beside the point I was making.

I don't think about putting a file into a buffer so I can edit it and then
write the buffer back to disk. I think about editing a file. Going through
the translation from how I think about this task and how it happens to be
implemented is an extra burden for me.

In point of fact I _don't_ mind the use of "buffer" in (X)Emacs. Partially
it's not relevant (for non-file buffers) and partly I'm used to it. It's
also a rather small issue. The reason I brought it up is because this way
of _thinking_ about it is, in my opinion, important. And not just for
Windows people or novices, but for more experienced people as well. Not
everyone can be an expert at everything; those that aren't expert (merely
competent) with Emacs would benefit greatly from any improvement in it's
human interaction. In fact, just about the only group of people who would
benefit little or not at all from it are those that are experts at Emacs.




-- 
By definition there is __no_way__ any problem can be my fault.  Any problems
you think you can find in my code are all in your imagination. If you continue
with such derranged imaginings then I may be forced to perform corrective
brain surgery... with an axe.                              -- Stephen Harris

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>Terje Bless <link@pobox.com> wrote:
>
>>I've been using XEmacs for programming since the early nineties. I
>>_still_ have no clue how to switch between buffers from the keyboard!
>
>Is this complaint about the documentation or about the functionality?

It's a data point. Take it into account or ignore it as you please.

It is unquestionably "a complaint", but the complaint wasn't it's main
purpose; I posted it to provide you with /my/ point of view. I thought you
might find it interesting because I judged my frame of reference to be
different from yours (and I'm adressing the generic plural here). :-)



-- 
"I don't want to learn to manage my anger;
 I want to FRANCHISE it!" -- Kevin Martin

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Andy Piper wrote:
>>There are tooltips for the toolbar?
> 
> Are you using XEmacs on windows or UNIX? On windows I made the help for the
> toolbar button appear in a tooltip.

Yeah, unix.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> Despite the dialogs, I tend to run my other editor entirely from the
>> keyboard.
>> 
>> In the Xemacs conmpletions buffer there is no hint of how to do this
>
> Doesn't it say something like 
>
>   In this buffer, type RET to select the completion near point.
>
> ?

It does -- this is what it looks like in XEmacs:

Click button2up on a completion to select it.
Type M-v or prior to move to this buffer, for keyboard selection.

Possible completions are:
[...]

XEmacs's keyboard selection in the completion buffer is even made to
more closely resemble to "traditional" model of selecting things --
for example, arrow keys move by items, not by characters in the
buffer.  Try it out and you'll see what I mean.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Terje" == Terje Bless <link@pobox.com> writes:

    Terje> Tooltips might help, but I wonder if they might not be too
    Terje> expensive to implement and maintain (they tend to be in the
    Terje> context of the analogous Mac OS Baloon Help) compared to
    Terje> their value. Not that it wouldn't be very helpfull for
    Terje> figuring out what various gizmos do, mind you!

In many cases we already have docstrings.  Truncate to first line (<=
80 characters by convention), reformat in <= 25 char lines, display in
small font.

Also, it wouldn't just be for gizmos, you could also do this with
buffer text.  (Suggests itself as a secondary "browser" interface for
a dictionary application, eg, for a novice in a foreign language---
just point, no click required.)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Wed, 24 Apr 2002, Terje Bless wrote:

> In the context of this specific discussion, I'm refusing to read the manual
> partly to illustrate a point and partially because it allows me the
> "innocent" perspective.

That's perfectly okay, but I'm deeply convinced that a tool of such 
flexibility cannot be used without consulting the documentation to some 
extent.  We need to make that documentation more accessible and more 
efficient in answering the specific question the user might have at any 
given point, but the look alone is IMHO insufficient to tell the user 
about all the possible gestures and operations she has at her disposal.

Making Emacs more intuitive requires an effort; making the docs more 
useful requires an effort as well.  These two efforts should be balanced, 
IMHO; saying that documentation should be (almost) irrelevant promotes 
the idea that one effort should be favored at the expense of the other, 
which I think is not a good idea, because I think it's impossible to 
reduce the need in documentation to the low level of the kind I thought
you were asking for.

> it's very easy
> to assume the position that if someone can't be bothered to put in a little
> effort to manage on their own, they don't deserve hand-holding from those
> that have put in a lot of effort over a lot of time to acquire the
> expertise they have.

I didn't assume such a position; if my wording somehow hinted of that, I 
apologize.  I was merely trying to figure out the peculiar (to me) 
position of trying to use a compex tool without consulting the docs.

In my experience, reading the manual once or twice is not enough: it is 
too large to remember.  You need to consult the manual every time you 
have a specific problem, using the manual as a reference.  Facilities 
such as `i' are a big help here.  I would even go as far as telling not 
to read the manual in its entirety at all, even once, except for the 
first few sections about the basics.  Instead, wait until you have a 
specific problem and look that up.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Robert J. Chassell]

   > Pressing `C-x b <tab>' gives you a "completions" buffer
   > And *poof* you've just thrown me into a new world; ...

Think of the <tab> as a key that pops up a menu, in this case, a menu
listing the names of certain files.  You could rebind it to a
different key, such as an ALT key.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Wed, 24 Apr 2002, Terje Bless wrote:

> 2. The expected meaning of buttons is "wrong" here; button2 is Select
>    and not Paste as it is everywhere else. Button1 does nothing, but
>    everywhere else it means Select. Button3 gives you unrelated options.
>    This is possibly the most confusing combination of behaviour for
>    mouse buttons that can be chosen in the context. And it's absolutely
>    unique to XEmacs.

That's true, Emacs traditionally has different conventions for mouse 
buttons.  The main problem (I think) is that mouse-1, the left button, 
moves point to where you click, switching windows and buffers as 
appropriate.  I don't see an easy solution to that, except to ease the 
burden a bit with tooltips and similar aids.

> 3. A dialog can be dismissed if you enter it by mistake. Just click
>    Cancel or hit ESC. Here, ESC does nothing, there is no Cancel button,

You can dismiss the pop-up window as well, just with different gestures.
We could have a "Dismiss" button inside it to make it easier.  I guess 
the assumtion is that, since you typed TAB, you will proceed by selecting 
one of the possible completions, after which the window pops down 
automagically.

> Despite the dialogs, I tend to run my other editor entirely from the
> keyboard.
> 
> In the Xemacs conmpletions buffer there is no hint of how to do this

Doesn't it say something like 

  In this buffer, type RET to select the completion near point.

?

> I'm sure you can switch from the minibuffer to the completions
> buffer from the keyboard, but I don't know how (see below). Trying the
> methods that are familiar from other environments -- and so have taken on
> the status of trained reflexes by now -- do not work.

Could you please tell what are those familiar methods?

> >I think you overestimate the price.  The price of using the Emacs manual
> >as a reference, via the `i' command, is normally quite low.  (The
> >abnormal cases usually constitute docs bugs.)  I suggest to try that,
> >perhaps you will find it easier than you thought.
> 
> Perhaps. What "i" command? "C-h i"?

No.  Type "C-h i", then "m xemacs RET" (or "m emacs RET", as the case may 
be), and _then_ type `i'.  This invokes an Info command which asks for a 
string and then looks up that string in the indices of the manual you are 
looking at, in this case the XEmacs manual.  A well-indexed manual should 
have every important concept as well as all standard commands, 
keystrokes, and variables in its indices.  So `i' will quickly find what 
you are looking for with a very high probability.

Let's conduct a little experiment, shall we?  Give me a couple of 
subjects that someone might wish to find quickly in the docs (perhaps 
some problems that bothered you in the past), and I will post an 
unabridged and uncensored description of how I looked for that.  (I can 
tell you in advance that my memory tends to forget many details, so you 
don't have to account for the possibility that I will know exactly where 
to look.)

> Oh great! These keybindings change depending on what buffer I'm in?

Of course they do.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Terje Bless wrote:
> Perhaps I just overestimate my own ability to adapt compared to the average
> user (arrogance was ever my vice, I'm afraid). I've adapted fairly well to
> this way of doing things.
> 
> Let me try to be more specific.
> 
> 
> 1. The split view is somewhat overloaded; it's used for both the
>    function that dialogs hold in other environments and for regular
>    split-view.

This list of UI problems is huge.  Maybe it'd be better off somewhere more 
permanent and easy to browse, like a web or wiki page?

Can we put this stuff on a wiki?  Maybe the emacs wiki?  Anybody know the url?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 23 Apr 2002, Brady Montz wrote:

> > Sounds good, but how does a user get into the ring in the first place?
> 
> Lessee, we currently have:
> 1. the help menu
> 2. the items on the splash page
> 
> those seem a good start. 

Yes, but I thought you were unhappy with the current UI that enters help, 
including the menu bar.  I thought you were suggesting something 
different...

> 1. a button on the toolbar and/or in the menu to describe the current modes.
> 2. "what's this?" tooltips or buttons.
> 3. a minor mode like eldoc that makes the symbols in your elisp files
>    clickable, just like we have for info and man pages. Click on a
>    symbol to find out more. 

...like this.

> "What's this?" might be particularly useful for the modeline. 

Emacs 21 implements some of that with tooltips that pop up depending on 
the area of the mode line where you place the mouse pointer.  For 
example, place it on the "%%" marker, and a tooltip will pop up saying 
"Read-only buffer, mouse-3 toggles".  I think this should be used in more 
parts of the display.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 23 Apr 2002, Brady Montz wrote:
> 
> > > Sounds good, but how does a user get into the ring in the first place?
> > 
> > Lessee, we currently have:
> > 1. the help menu
> > 2. the items on the splash page
> > 
> > those seem a good start. 
> 
> Yes, but I thought you were unhappy with the current UI that enters help, 
> including the menu bar.  I thought you were suggesting something 
> different...

I'm mildly unhappy with the current UI, in that the entry points are
fairly cryptic. That's easily fixed. The greater unhappiness is that
the help system is a bit of a maze (unavoidable), and which entrance
you take decides a lot about the route you take, and the lack of
cross-linking between the paths makes it tricky to jump from one to
the next. So, the first decision the user makes has much more weight
than it should, and it's probably the decision where he has the least
information. And it's a cryptic choice.

So, better linkage upfront, with a single help dialog box (but not
mandated). And better linkage later in case I want to wander a
different route through the help maze.

And, perhaps ironically, if we have a more fluid way of navigating the
maze, we can have even more entry points. Like tooltips.

> > 1. a button on the toolbar and/or in the menu to describe the current modes.
> > 2. "what's this?" tooltips or buttons.
> > 3. a minor mode like eldoc that makes the symbols in your elisp files
> >    clickable, just like we have for info and man pages. Click on a
> >    symbol to find out more. 
> 
> ...like this.
> 
> > "What's this?" might be particularly useful for the modeline. 
> 
> Emacs 21 implements some of that with tooltips that pop up depending on 
> the area of the mode line where you place the mouse pointer.  For 
> example, place it on the "%%" marker, and a tooltip will pop up saying 
> "Read-only buffer, mouse-3 toggles".  I think this should be used in more 
> parts of the display.

Stuff like that is nice. Especially if it doesn't slow you down. I
long since turned off the "oh, you coulda typed this key instead"
because the message was inline with my action, and slowed it
down. Tooltips are nicely unobtrusive.

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>On Sun, 21 Apr 2002, Terje Bless wrote:
>
>>>>>Pressing `C-x b <tab>' gives you a "completions" buffer
>>>>
>>>>And *poof* you've just thrown me into a new world; "Mommy this is
>>>>_confusing_! My window just split in two and half my text is hidden.
>>>
>>>How is this different from a dialog that pops up and obscures part of
>>>the display?
>>
>>All things being equal, it wouldn't be. Not by much anyway.
>>
>>But in this there is the matter of what people are used to and expect.
>>In a graphical editor, popping up a dialog is the normal way to handle
>>this.
>
>I think you overestimate the power of old habits and underestimate the
>ability of people to learn new ones.  The completions buffer popping up
>might surprise someone the first time they see it (although Bash and
>tcsh users are probably used to that already), but in my experience
>(observing people who converted from Visual Studio etc.) it doesn't take
>more than a couple of times to get used to it.

Perhaps I just overestimate my own ability to adapt compared to the average
user (arrogance was ever my vice, I'm afraid). I've adapted fairly well to
this way of doing things.

Let me try to be more specific.


1. The split view is somewhat overloaded; it's used for both the
   function that dialogs hold in other environments and for regular
   split-view.

2. The expected meaning of buttons is "wrong" here; button2 is Select
   and not Paste as it is everywhere else. Button1 does nothing, but
   everywhere else it means Select. Button3 gives you unrelated options.
   This is possibly the most confusing combination of behaviour for
   mouse buttons that can be chosen in the context. And it's absolutely
   unique to XEmacs.

3. A dialog can be dismissed if you enter it by mistake. Just click
   Cancel or hit ESC. Here, ESC does nothing, there is no Cancel button,
   and the "magic incantation" C-g may need to be pressed one or two
   times depending on what to me appears as arbitrary criteria (they're
   not of course, but I haven't figured out what they are yet); assuming
   you even know about C-g.

But even in light of this, I'm not necessarily suggesting the use of a
dialog for this. The dialog suggestion I made was specifically as an
alternate interface to the various search and replace commands. The
completions buffer has some problems from my point of view, but I'm not
sure what can be done to remedy them, or indeed if they warrant "fixing" at
all.



>>A dialog also has some advantage that the split screen approach does
>>not have; chiefly that of following a stratageme of direct
>>manipulation. You don't have to weasel out what keys you can press to
>>achieve something. All the options that you need are avilable as
>>clearly labelled text fields or buttons.
>
>I hope you are aware that the completions popped up by Emacs are
>clickable. Move your mouse pointer across the completions and observe
>the magic.

Despite the dialogs, I tend to run my other editor entirely from the
keyboard.

In the Xemacs conmpletions buffer there is no hint of how to do this (see
below). I'm sure you can switch from the minibuffer to the completions
buffer from the keyboard, but I don't know how (see below). Trying the
methods that are familiar from other environments -- and so have taken on
the status of trained reflexes by now -- do not work. And the look of the
buffer doesn't hint at how it could be manipulated. Once there I can move
around fairly well and guessing that Return activates seems to be right.

But only when I begin to study this buffer in composing this reply do I
notice that there is some text up there. Aha, I can use M-v to move there.
Why M-v? What possible heuristic could it have? Could it be because TAB is
already taken for minibuffer completion that it isn't used? TAB is what's
used everywhere else for switching between panes and text fields.

And the completions buffer doesn't look like a control; it looks like text.
You don't expect to be able to manipulate it as a control. Data should be
kept distinct from controls because you manipulate them in different ways.

And the buffers listing crams a lot into a single screenfull, but it
doesn't make it easy to select from the list. You need to consider too many
columns in what appears to be a bastardized semi-alphabetical order. Maybe
this is a fair tradeoff of power over simplicity. I know it's more
confusing then convenient for me, your MMV.



>>I allready do want to use more of them, and to use those I allready use
>>more efficiently. But I have made a concious choice that the price of
>>admission is too high. I make do with what I have because I'm not
>>willing to pay the price of admission to get the rest of the features.
>
>I think you overestimate the price.  The price of using the Emacs manual
>as a reference, via the `i' command, is normally quite low.  (The
>abnormal cases usually constitute docs bugs.)  I suggest to try that,
>perhaps you will find it easier than you thought.

Perhaps. What "i" command? "C-h i"? That gives me 340 lines of mostly
incomprehensible text. The first 60 of which we should probably shoot Red
Hat for leaving as "[No description avilable]". The remaining lines giving
me what appears to be the info pages for the GNU utils.

The plain "i" does nothing, though I see it's supposed to be bound to...
Hmmm... That's funny.. I could have sworn... Oh great! These keybindings
change depending on what buffer I'm in?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Kai Groþjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:

>Terje Bless <link@pobox.com> writes:
>
>>Hrvoje Niksic <hniksic@arsdigita.com> wrote:
>>
>>>Pressing `C-x b <tab>' gives you a "completions" buffer
>>
>>And *poof* you've just thrown me into a new world; "Mommy this is
>>_confusing_! My window just split in two and half my text is hidden. I
>>don't know what to do!"
>
>What do you use to open files?

The same as you probably, but only after the pain of trying to do it with
the mouse got to be too much some years back. For this I would much rather
have the familiar, if far less powerfull, native file select widget. It's
familiar so even if it isn't intuitive it's at least consistent.

But the switch to buffer bit is simply that me and Hrvoje are speaking of
slightly different things. Switch to buffer by name is there, but I'd like
to cycle through buffers sequentially; analogous to switching between
applications using Alt-TAB on Windows or Cmd-TAB on Mac OS.

A simple repetetive action instead of a single complicated one.

This is probably just because I tend to have far fewer buffers then Hrvoje,
or maybe I'm just weird or whatever. :-)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Sean MacLennan]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1627 bytes --]

Terje Bless writes:

 > But the switch to buffer bit is simply that me and Hrvoje are speaking of
 > slightly different things. Switch to buffer by name is there, but I'd like
 > to cycle through buffers sequentially; analogous to switching between
 > applications using Alt-TAB on Windows or Cmd-TAB on Mac OS.
 > 
 > A simple repetetive action instead of a single complicated one.

I have attached some sample code that does just what you want
;-) You probably want to attach it to a key though. Email me privately
if you want help with that. I have only tested it in XEmacs.

I wrote this for a new emacs user who wanted just what you said, an
Alt-TAB for buffers. However, most people tend to keep the number of
windows on their desktop to a relatively low number. Too many windows
and the desktop gets so cluttered that you cannot deal with the
windows. Plus, you will tend to run out of memory :-)

On the other hand, the number of buffers in an active emacs session
can get huge. I have had my current emacs session running for about 2
hours and have not been doing any majour development, just email and
this and that. I am up to 30 buffers. At work I can easily have
sessions running for days with hundreds of open buffers.

The above user quickly gave up on the command, so it is not heavily
tested :-) It also probably needs a previous-buffer command since if
you overshoot the buffer you have to go through the entire list again.

Now, both the user and I are developers. Maybe in a different
environment the command would be useful. If so, maybe something like
this should go in emacs.

Cheers,
   Sean MacLennan


[-- Attachment #2: next-buffer.el --]
[-- Type: text/plain, Size: 1124 bytes --]

(require 'iswitchb)

(defvar next-buffer-depth 0)

(defun next-buffer ()
  (interactive)
  (let (buflist len buf)
    ;; This is a stripped down version of `iswitchb-make-buflist'.
    ;; I want to use `iswitchb-ignore-buffername-p' instead of
    ;; duplicating the work.
    (setq buflist
	  (delq nil
		(mapcar
		 (lambda (x)
		   (let ((b-name (buffer-name x)))
		     (unless (iswitchb-ignore-buffername-p b-name)
		       b-name)))
		 (buffer-list))))
    ;; However, I do not want the current buffer in the list
    (setq buflist (delq (buffer-name) buflist))

    (if (eq last-command 'next-buffer)
	(progn
	  (setq len (1- (list-length buflist)))
	  (if (eq next-buffer-depth len)
	      ;; Just keep taking the tail of the list
	      (setq buf (nth next-buffer-depth buflist))
	    (progn
	      (setq next-buffer-depth (1+ next-buffer-depth))
	      (setq buf (nth next-buffer-depth buflist)))))
      ;; This is the first next-buffer
      (setq next-buffer-depth 0)
      (setq buf (car buflist)))
    (if (not buf) (error "No other buffers"))
    (switch-to-buffer buf)))

(global-set-key [f11] 'next-buffer)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kai Großjohann]

Terje Bless <link@pobox.com> writes:

> But the switch to buffer bit is simply that me and Hrvoje are speaking of
> slightly different things. Switch to buffer by name is there, but I'd like
> to cycle through buffers sequentially; analogous to switching between
> applications using Alt-TAB on Windows or Cmd-TAB on Mac OS.

I see.  Sadly, there is no really standard way to do this.  Various
approaches have various pros and cons.

I wonder if it would make sense to bind bury-buffer to a key.  Terje,
would you be willing to try M-x bury-buffer RET a couple of times to
see if it would be useful to have that bound to a key?

The problems with bury-buffer are that it only goes in one direction,
and it might display some buffers that you are not interested in.

Various packages exist that solve these problems, but none of these
seems to have emerged as the standard way to do it.

kai
-- 
Silence is foo!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Jan D.]

> 
> Kai Gro=FEjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
> 
> But the switch to buffer bit is simply that me and Hrvoje are speaking of
> slightly different things. Switch to buffer by name is there, but I'd like
> to cycle through buffers sequentially; analogous to switching between
> applications using Alt-TAB on Windows or Cmd-TAB on Mac OS.
> 

In Emacs 21 you can click with button 1 on the buffer name in the modeline
to cycle forward, and button 3 to cycle backward.  There is a tooltip
that says this when the mouse is over the buffer name.

Where I work some people where used to Microsoft style cycling so I made
some lisp to do that.  But now they use only the modeline.

	Jan D.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Making all code that displays or parse docstrings somehow support
> :link as well isn't the best approach.

How much code is that, apart from describe-variable and
customize-variable (which should be one)?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Richard Stallman]

    > I think that's not the best solution for this problem, since there's
    > already enough information to make such a connection automatically in
    > the great majority of cases.

    Are you saying that customize should adopt the "See info node" docstring 
    magic instead?

I think that would be better.  For one thing, it lets you control
where in the doc string the link appears.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

    >> Furthermore, Eli implies that the cost of reducing the barriers
    >> is quite high (elsewhere in the thread).

    Eli> I guess this depends on your definition of ``quite high''.

Same as yours:

    Eli> In general, work on documentation requires a large effort,
    Eli> even just to keep the docs up-to-date.  It might, for
    Eli> example, tie up one or two dedicated volunteers full time.

And I share your concern that the kinds of changes we're discussing
are likely to add burdens of nearly this order of magnitude (+20%, say).

So we need to be smart about these kinds of changes.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Matthew Toomim]

Eli Zaretskii wrote:
> Well, yes and no.  Terje seemmed to say that he didn't want to read the 
> manual, period.  Not even a single section, not even when in bad need of 
> some specific information.  That sounds extreme to me: if there's a way 
> of getting quickly to the necessary info, why should someone refuse to do 
> that on purpose?

I think this is the crux of the disagreement: you seem to imply that 
this issue is a matter of desert.

What the above paragraph implies, is that you think Terje doesn't 
deserve to use the cool features in XEmacs, or that we should not feel 
obligated to make the features easier to use, if he is not willing to 
put in the effort required to read the XEmacs manual.

I think that this is missing his point.  Terje isn't complaining to us 
that he can't use the features; he is trying to show us how to get more 
people to use XEmacs.  He is showing us that there are certain barriers 
to entry that don't need to be there, and that these barriers cause a 
lot of people to miss out on the power that XEmacs provides.

Whether the general mainstream audience has put in enough effort to 
really *deserve* to use XEmacs isn't the issue here.  The issue is 
whether or not XEmacs has the best UI that it could have.

Michael

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> Date: Tue, 23 Apr 2002 11:38:47 -0700
> From: Michael Matthew Toomim <toomim@cs.berkeley.edu>
> 
> Eli Zaretskii wrote:
> > Well, yes and no.  Terje seemmed to say that he didn't want to read the 
> > manual, period.  Not even a single section, not even when in bad need of 
> > some specific information.  That sounds extreme to me: if there's a way 
> > of getting quickly to the necessary info, why should someone refuse to do 
> > that on purpose?
[...]
> What the above paragraph implies, is that you think Terje doesn't 
> deserve to use the cool features in XEmacs, or that we should not feel 
> obligated to make the features easier to use, if he is not willing to 
> put in the effort required to read the XEmacs manual.

Sorry, I don't understand how did you deduce that from my language.  I
never meant anything like that.  What part of my wording implied such
a hostile intent?

All I meant to say was what I said: that it surprises me why would
someone avoid existing documentation even though it might be easily
accessible and helpful.

> Whether the general mainstream audience has put in enough effort to 
> really *deserve* to use XEmacs isn't the issue here.

I don't think in such categories.  To me, anyone and everyone
deserves to use XEmacs.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>Sorry, I don't understand how did you deduce that from my language.  I
>never meant anything like that.  What part of my wording implied such a
>hostile intent?

For the record, I'd conclude simply that you disagree with me, no more no
less. Allthough I must admit to feeling some (perhaps imagined) hostility.
Not necessarily from your replies to me alone, but as an overall impression
from the combination of replies.

But lets not sidetrack here. I'm quite certain no one intends any hostility
and certainly no harm. If tempers flare anywhere it's no more then par for
the course when discussing technical subjects you have a lot vested in and
strong opinions about.

And those that know me from other context know I can get pretty pissy
myself without really meaning anything by it; so I'm certainly not going to
take offence at being on the other side of it.


>All I meant to say was what I said: that it surprises me why would
>someone avoid existing documentation even though it might be easily
>accessible and helpful.

Are you asking in the general or in the specific?

In general, many people will have a high threshold for seeking the
documentation because XEmacs is a tool, a mere editor, and not an end in
itself. The more invisible it is the better. Only after some time's use and
having seen the hints of further power avilable will most be willing to
invest the time and effort in reading the documentation.

In my specific case, I kind of lie to you. I have read the manual
(allthough it was many years ago). Not that any of it actually stuck (I'm
too casual a user of XEmacs for that), but I did read it. The reason I
haven't used the documentation more actively as my use of XEmacs increased
is because I manage to get what I need done without it. I know there is
more power here, and I know I could increase both my efficiency and my
pleasure in working with XEmacs by learning it better, but so far short
term convenience has won out.

In the context of this specific discussion, I'm refusing to read the manual
partly to illustrate a point and partially because it allows me the
"innocent" perspective. Every single person on this list knows XEmacs
better then me, but that also means they have preconceived notions and look
at issues through a veil of expectation.


Think about it as hiring a new person for your team. They come in and see
with fresh eyes. They aren't blinded by the "but this is how it's always
been done" syndrome. A lot of the time they're full of crap and lack the
experience to find a realistic solution. But the _ideas_, the new ways of
seeing things, is immensely valuable if those who /do/ have the experience
manage to pick up the good ideas and views and temper them, turn them into
practice.


>>Whether the general mainstream audience has put in enough effort to
>>really *deserve* to use XEmacs isn't the issue here.
>
>I don't think in such categories.  To me, anyone and everyone deserves
>to use XEmacs.

No, I don't think anyone does, at least not conciously. But it's very easy
to assume the position that if someone can't be bothered to put in a little
effort to manage on their own, they don't deserve hand-holding from those
that have put in a lot of effort over a lot of time to acquire the
expertise they have. This is a bare necessity when you deal with users on
mailinglists or USENET or whatever, but it tends to cloud your judgement
when thinking about possible improvements to the system.

At least, this has been my experience.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Eli Zaretskii wrote:
> Sorry, I don't understand how did you deduce that from my language.  I
> never meant anything like that.  What part of my wording implied such
> a hostile intent?
> 
> All I meant to say was what I said: that it surprises me why would
> someone avoid existing documentation even though it might be easily
> accessible and helpful.

> I don't think in such categories.  To me, anyone and everyone
> deserves to use XEmacs.
> 

You're right.  I'm sorry, I just re-read what you said in light of your 
comments, and I take back what I said in that post.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

    Eli> looking up the function in the indices of the Info manual
    Eli> associated with the function whose name you type.

Do you mean that as written, ie, functions somehow get a
'info-manual-name property (seems unlikely but possible), or do you
mean (as implied by your reference to INFOPATH) that Emacs looks in
the index of every manual on INFOPATH etc?

That would be ridiculously slow on Debian systems where it is _policy_
to gzip the info manuals.  (In fact, this is the source of regular
complaints about XEmacs: info mode is very slow to start up because
XEmacs searches all the manuals to generate the (dir) node.)

    Eli> Unless "C-h C-f" works differently in XEmacs, that is.

I'll have to look, seems likely given the difference in performance
(as C-h i d m gnus RET does work as expected, except on Debian where
they reference the GNU Emacs versions of all the manuals in the (dir)
node, and bury manuals from XEmacs under xemacs21::).


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 23 Apr 2002, Stephen J. Turnbull wrote:

> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
>     Eli> looking up the function in the indices of the Info manual
>     Eli> associated with the function whose name you type.
> 
> Do you mean that as written, ie, functions somehow get a
> 'info-manual-name property (seems unlikely but possible), or do you
> mean (as implied by your reference to INFOPATH) that Emacs looks in
> the index of every manual on INFOPATH etc?

The former: Emacs has a set of rules to know in which manual to look
for the documentation of a given function.  See the alist called
`Info-file-list-for-emacs' defined in info.el.

> except on Debian where
> they reference the GNU Emacs versions of all the manuals in the (dir)
> node, and bury manuals from XEmacs under xemacs21::).

Yes, that's a known gripe about Debian.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Simon Josefsson]

On Mon, 22 Apr 2002, Per Abrahamsen wrote:

> Simon Josefsson <jas@extundo.com> writes:
> 
> > Making all code that displays or parse docstrings somehow support
> > :link as well isn't the best approach.
> 
> How much code is that, apart from describe-variable and
> customize-variable (which should be one)?

I wasn't objecting to changing the code based on the amount of code (which
I'm sure is quite small) but because it means people handling docstrings
need to have a mental model that not all documentation for a symbol is
stored in the docstring, and that they may need to look elsewhere as well
to get the complete picture.  If all documentation (including references)
is stored within the docstring, people handling docstrings will get all of
the documentation without having to know or care about this at all.

In any case, I think we agree that the real problem is to get lisp
programmers to start to add references and having them end up as visible
to the user.  The way it is implemented isn't interesting or important
(but that hasn't stopped me from having an opinion before ;-)).

Suggestion: Add something to the Lisp manual on how to write
docstrings that have references when defining symbols.  I haven't seen the 
"See Info node" magic explained anywhere.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 22 Apr 2002, Miles Bader wrote:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > The manual should be indexed well enough to allow you to find any
> > important issue within seconds by using the `i' command.  If you
> > cannot find some issue via `i', I suggest to file a docs bug report.
> 
> Come to think of it, why not automatically add clickable references from
> doc-strings into the info manual?

A good idea, IMHO.  It could create a "More Info" button in the *Help* 
buffer, for example.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Andy" == Andy Piper <andy@xemacs.org> writes:

    >> The feature of using toolkit widgets seems very powerful.
    >> Could you find out the names of all the people who wrote the
    >> code which implements this?  If they are willing to sign
    >> papers, maybe we could use the code in Emacs.

    Andy> I think the copyright for this particular feature is almost
    Andy> exclusively owned by me. However, the code all relies on
    Andy> support that Ben wrote - so you would need to get papers
    Andy> from both Ben and me.

Are you sure?  There has long been support for subwindows (but it's
been broken since 19.1something).  Are you sure you used none of that,
or did you write that in a previous incarnation?  Also, anything that
Ben wrote is almost certainly polluted with Sun copyrights.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>On Sun, 21 Apr 2002, Terje Bless wrote:
>
>>But a lot of the time I'm hindered by the fact that Emacs insists on me
>>adapting to it, instead of it adapting to me. It "DWIMs" fairly well in
>>some situations, but a lot less well in others. And writing lisp code
>>is considered an acceptable way to interact with Emacs for normal users!
>
>A list of specific problems you have, in those situations where Emacs
>doesn't DWIM, would be nice.  It's hard to fix problems that are
>unnamed.

Understood, but mostly I'm not sufficiently familiar with either of the
Emacsen to be of much help. I'd waste too much time suggesting feature
this-and-that which is already there and wasting developer's time.

Sorry.


>>But the real point of all this isn't any specific feature or
>>implementation detail. The main point I'd like to make is that, again
>>in my opinion, the single most important factor in making Emacs more
>>accessible to more people is to start giving more weight to these
>>issues (and, yes, as a consequence less weigth to other issues; it's a
>>tradeoff when resources are limited).
>
>I think this is already done.  That's why specific details are
>important: the tendency to make Emacs more usable is already there, but
>I have no doubt that more work is needed to actually make that happen.

If it's already done then I'm preaching to the choir. I'm piping up here
because my impression is that there is a severe lack of focus on this area
and that it somehow "should" be better if that focus was really there.

But I may very well be wrong!



>>The perfect feature needs no documentation because it's intuitively
>>obvious how it works.
>
>This is only true for very simple features.  Powerful and flexible
>features are normally complicated enough to require some documentation,
>without which they are less useful than they could have been.

I disagree. This is IMO true of any feature, it just isn't possible to
achieve in practice for more then a very small fraction of features. My
complaint here is that the Emacsen do not go far /enough/ in the direction
of perfection and settle too easily.


>>But there is also a possibility that Emacs just isn't the tool for me.
>>Perhaps it's too advanced a tool for my simple use and I should stay
>>with less powerfull, but also more easy to understand tools. That's a
>>valid point of view. I'd like to see Emacs cater to me also
>
>That's what the menus and the tooltips are supposed to accomplish, I
>think.

Yes, and they are what enable me to use XEmacs at all! The price of entry
would otherwise be too high.


>>and I firmly believe it can do that without compromising away the power
>>it has that more advanced users need.
>
>I don't believe this is possible.  Simplicity and power do contradict to
>some degree.  I agree with the general tendency to not trade power for
>simplicity, but in practice, beyond a certain level, power comes at the
>expense of simplicity.  That's why other editors praised for their
>simplicity are much less powerful than Emacs.

Ok, then we disagree here. Perhaps I'm just hopelessly optimistic, but I
really do think it's possible to make Emacs easier to use without
compromizing it's power, at least not unduly.


-- 
Every morning in Africa,  a gazelle wakes up.  It knows it must run faster
than the fastest lion or it will be killed.  Every morning a lion wakes up.
It knows  it must outrun the  slowest gazelle or  it will starve  to death.
It doesn't matter whether you are  a lion or a gazelle: when the sun comes
up, you'd better be running...

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> Date: Sun, 21 Apr 2002 17:29:27 +0200
> From: Terje Bless <link@pobox.com>
> 
> >>The perfect feature needs no documentation because it's intuitively
> >>obvious how it works.
> >
> >This is only true for very simple features.  Powerful and flexible
> >features are normally complicated enough to require some documentation,
> >without which they are less useful than they could have been.
> 
> I disagree. This is IMO true of any feature, it just isn't possible to
> achieve in practice for more then a very small fraction of features.

Since I'm not interested in theretical possibilities that cannot be
realized in practice, it sounds like we agree ;-)

> My
> complaint here is that the Emacsen do not go far /enough/ in the direction
> of perfection and settle too easily.

Without specific examples (which you already declined to provide),
this complaint isn't useful, since we agree in principle that we
should try to avoid trading simplicity for power as much as possible.

> >Simplicity and power do contradict to
> >some degree.  I agree with the general tendency to not trade power for
> >simplicity, but in practice, beyond a certain level, power comes at the
> >expense of simplicity.  That's why other editors praised for their
> >simplicity are much less powerful than Emacs.
> 
> Ok, then we disagree here. Perhaps I'm just hopelessly optimistic, but I
> really do think it's possible to make Emacs easier to use without
> compromizing it's power, at least not unduly.

I don't think it's a question of optimism.  I think it's a question of
experience.

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

> >That's what the menus and the tooltips are supposed to accomplish, I
> >think.
>
> Yes, and they are what enable me to use XEmacs at all! The price of entry
> would otherwise be too high.

So should we implement generic tooltips - rather than just for the toolbar?
I can see this as a very powerful feature if somebody put in the time to
write helpful text for various parts of the editor.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Matthew Toomim]

Andy Piper wrote:
> So should we implement generic tooltips - rather than just for the toolbar?
> I can see this as a very powerful feature if somebody put in the time to
> write helpful text for various parts of the editor.

There are tooltips for the toolbar?  Are you referring to the help-echo 
property on extents?  I'm curious about this feature.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Michael Matthew Toomim <toomim@cs.berkeley.edu> writes:

> Andy Piper wrote:
>> So should we implement generic tooltips - rather than just for the toolbar?
>> I can see this as a very powerful feature if somebody put in the time to
>> write helpful text for various parts of the editor.
>
> There are tooltips for the toolbar?

(balloon-help-mode 1)

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

> There are tooltips for the toolbar?  Are you referring to the help-echo
> property on extents?  I'm curious about this feature.

I think I can even claim credit for thinking up this particluar feature in
the dim and distant past :) But for me help-echo is not in-your-face enough
since it prints to the echo area. Hence tooltips like those on the toolbar.

andy

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

> There are tooltips for the toolbar?

Are you using XEmacs on windows or UNIX? On windows I made the help for the
toolbar button appear in a tooltip.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Andy Piper <andy@xemacs.org> wrote:

>>>That's what the menus and the tooltips are supposed to accomplish, I
>>>think.
>>
>>Yes, and they are what enable me to use XEmacs at all! The price of
>>entry would otherwise be too high.
>
>So should we implement generic tooltips - rather than just for the
>toolbar? I can see this as a very powerful feature if somebody put in
>the time to write helpful text for various parts of the editor.

Tooltips might help, but I wonder if they might not be too expensive to
implement and maintain (they tend to be in the context of the analogous Mac
OS Baloon Help) compared to their value. Not that it wouldn't be very
helpfull for figuring out what various gizmos do, mind you!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Alex Schroeder]

"Andy Piper" <andy@xemacs.org> writes:

> I think the issue is not so much that Emacs uses weird terminology but that
> Emacs uses different terminology to a hundred other editors. Seems like
> we're arguing for Esperanto rather than words that are actually in the
> dictionary.

True enough.  But will we change the terminology again when the next
paradigm change of software development happens?  I think it would be
foolish to assume that Windows and Documents will be around for the
next decades.  Thus we might as well stick to our own pre-Windows,
pre-X terminology.  My favorite quote in this context from a posting
by Per:

    What you call "Windows" is just one of many window systems that
    has come in and out of fashion during the lifetime of Emacs. Emacs
    (in one version or another) has supported most of them, SunView?,
    X10, X11 (Open Look, Athena, Motif), PM, Win32, Mac. Emacs has
    provided a sound foundation that has allowed programmers to be
    productive with all these, and will also provide a foundation for
    whatever window system will be hot tomorrow.

    What Emacs doesn't do is to give up that foundation in order to
    follow the latest trend. Instead, it incorporates what is good and
    compensates for the rest. This -- off course -- will make Emacs
    feel "old" for the followers of hype, but the wise will see its
    intrinsic power and lasting value.

    -- Per Abrahamsen, http://www.emacswiki.org/cgi-bin/wiki.pl?EmacsDefense

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Andy" == Andy Piper <andy@xemacs.org> writes:

    Andy> I think the issue is not so much that Emacs uses weird
    Andy> terminology but that Emacs uses different terminology to a
    Andy> hundred other editors. Seems like we're arguing for
    Andy> Esperanto rather than words that are actually in the
    Andy> dictionary.

    >> -----Original Message-----

Followed by about 100 lines of uninterrupted quote.

Talking about Emacs requires a much bigger vocabulary than talking
about text widgets that cause intelligent people to top-post.

It's true that we do use words like "file" and "window" differently
from other editors, but the distinctions that cause these distinct
usages will not go away without drastically changing Emacs, and
reducing its capabilities.

It's true that many of the "programmer's editors" you advocate that
Emacs emulate have specialized capabilities we can dream of having in
a year or two at best, but none of them provide the kind of
flexibility that Emacs does.  Describing that flexibility precisely
and accurately does require words that are only found in unabridged
dictionaries, or in specialist's jargon glossaries.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Terje Bless <link@pobox.com> writes:

> Actually, it's slightly worse. I use
>
>   '(buffers-menu-submenus-for-groups-p t)
>
> (I have no idea what this feature is /really/ called)

So do I.  Except I don't use the menus, I just like how they look.
:-)

> and the "Switch to Buffer" command in the buffer sub-menu lists no keyboard
> shortcut.

I'm not sure what you mean by "the buffer sub-menu", but in the
menubar, the "Buffers" menu contains a "Go to buffer..." item which is
marked with `C-x b' -- and that's how you switch buffers using
keyboard.

> The lack of a command to go to a named buffer is irrelevant; doing
> that involves so much typing I'd rather select it from the menu.

De gustibus...  In my case, "much typing" is tempered by the fact that
you have completion, probably the best UI invention pushed by
Unix-like systems.  Especially Emacs's completion feature, which
tightly connects keyboard and mouse.

Pressing `C-x b <tab>' gives you a "completions" buffer and three
choices:

* Insert text, using TAB for further completion.  Enter chooses a
  reasonable default -- last used buffer.  (I use this method.)

* Press PgUp to get to the "completions" buffer, and navigate it using
  the cursor keys.  Notice how the cursor keys move by items rather
  than by characters.  Also notice how pressing RET does The Right
  Thing.

* Find the wanted selection and click with button2 to choose it.

If that's not full-featured, I don't know what is.  I've never felt
the need for any of the "advanced" buffer switchers, and I was
appalled whenever I tried one of them.

> Well, from my point of view, it certainly can. As we discussed some
> years ago Hrvoje, from my point of view (X)Emacs is a mere editor;

I'm afraid I don't remember our previous discussions, but I can
certainly see your point here.  What I don't understand is why you
keep using XEmacs.  Although Emacs is a decent editor, I'm sure there
are ones as good, but without the "burden" of Lisp and
programmability.

> So to improve the "manual" for /me/ you'd have to remove every
> reference to lisp from it.

I don't think the XEmacs manual makes all that many references to
Lisp.  Have you actually read it?  Of course, by "manual" I don't mean
the Lispref, but the actual XEmacs Reference Manual.

To take another example, look at my description of `C-x C-b <tab>'
above.  How much Lisp did I use?

> Or maybe I just wish to redefine what is the "average" user of Emacs.
>
> Right now, as far as I can tell, the "average" user knows more then
> average (if you'll pardon the pun) about lisp and the implementation
> details of Emacs. There is a fairly large barrier to entry. When you
> pass it it will scale upwards very well, but it doesn't scale _down_
> at all well. There is this huge gap between doing everything from
> the menus and writing your own custom lisp bits to make Emacs behave
> the way you want it to.

I see your point, I really do, but I don't have a good idea how to
fill this gap.  I think the tools like `M-x edmacro' (have you tried
it? -- `M-x edit-kbd-macro') are a good first step because they make
it easy to translate keystrokes and the "editing" stuff you see into
the Lisp stuff underneath.  Then it's not hard to mess with the Lisp
stuff without having to have a deep understanding about it.  `M-x
customize' is another example of the same, but fails to deliver for
similar reasons -- still too complex and "hard".

We have a long way to go, and I'm not sure Emacs will ever fit the
bill here.  Part of the problem is that, once you overcome the
barrier, you are no longer part of the target group, and you even
begin to *like* the way Emacs does things.  It seems like a tar pit,
but I can't sympathize with that view and be entirely honest -- I've
been assimilated.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Hrvoje Niksic <hniksic@arsdigita.com> writes:
> > The lack of a command to go to a named buffer is irrelevant; doing
> > that involves so much typing I'd rather select it from the menu.
> 
> De gustibus...  In my case, "much typing" is tempered by the fact that
> you have completion, probably the best UI invention pushed by
> Unix-like systems.

Indeed; I rarely type more than 2-3 characters of a buffer name when
switching to it with C-x b, and I usually have _lots_ of buffers...

It's the sort of thing that may seem very annoying and inconvenient to
someone that doesn't use it, but once you've used it for a while, you
realize, it's really not.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Hrvoje Niksic wrote:
> I see your point, I really do, but I don't have a good idea how to
> fill this gap.  I think the tools like `M-x edmacro' (have you tried
> it? -- `M-x edit-kbd-macro') are a good first step because they make
> it easy to translate keystrokes and the "editing" stuff you see into
> the Lisp stuff underneath.  Then it's not hard to mess with the Lisp
> stuff without having to have a deep understanding about it.  `M-x
> customize' is another example of the same, but fails to deliver for
> similar reasons -- still too complex and "hard".

Wait.. isn't this the whole point of this thread?  I thought this was about 
figuring out what what could be done to XEmacs to make it more mainstream -- 
to make it usable to those who haven't been assimilated?

In my mind, XEmacs provides a few very cool features that aren't dependent 
upon the lisp extensibility (other than in that they grew out of lisp 
extensions) that would be extremely useful to the mainstream user: i-search, 
program-code auto-indentation, iswitchb, full-featured syntax highlighting, 
etc. as well as more than a few more advanced features that enhance one's 
intimacy with the editor: dynamic abbrevs, structural navigation (C-M-d, 
C-M-b, etc.), and the like.

In my mind, the point behind this "the future of XEmacs" idea is to figure out 
how to generate a version (or dialect) of XEmacs that gives mainstream users 
access to the really cool functionality that XEmacs has to offer.

If we don't think that XEmacs can ever "fill the gap"; that it can ever be 
useful to a user who isn't willing or prepared to go through the hazing 
ritual, then why are we even talking about this at all?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Sun, 21 Apr 2002, Hrvoje Niksic wrote:

> > So to improve the "manual" for /me/ you'd have to remove every
> > reference to lisp from it.
> 
> I don't think the XEmacs manual makes all that many references to
> Lisp.

Neither do I.  It's possible that a few references are here and there, 
but by and large, Lisp is not an important player in the user manual.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Hrvoje Niksic <hniksic@arsdigita.com> wrote:

>Terje Bless <link@pobox.com> writes:
>
>>Actually, it's slightly worse. I use
>>
>>'(buffers-menu-submenus-for-groups-p t)
>[...]
>>and the "Switch to Buffer" command in the buffer sub-menu lists no
>>keyboard shortcut.
>
>I'm not sure what you mean by "the buffer sub-menu", but in the menubar,
>the "Buffers" menu contains a "Go to buffer..." item which is marked
>with `C-x b' -- and that's how you switch buffers using keyboard.

I'm struggling with the limits of my Emacs vocabulary here, but I have the
Buffers menu set up to group buffers by type (that "mode" rather, probably,
no?) and to give each group of buffers their own sub menu. And I've
switched on the sub-menu for each buffer menu that gives you commands like
"Switch to Buffer" and "Switch to Buffer, Other Frame" etc.

The only command listed with a keyboard shortcut in my XEmacs is the "List
All Buffers" command.


>>The lack of a command to go to a named buffer is irrelevant; doing that
>>involves so much typing I'd rather select it from the menu.
>
>De gustibus...  In my case, "much typing" is tempered by the fact that
>you have completion,

Well, certainly (to both). I just prefer to cycle sequentially through
buffers until I hit the right one. Anyways, my point was that I hadn't yet
figured out how to do it rather than complain of the lack. Or put another
way, either I don't learn well or XEmacs doesn't teach well. Take your
pick! :-)


>probably the best UI invention pushed by Unix-like systems.

Yes, without question! :-)


>Pressing `C-x b <tab>' gives you a "completions" buffer

And *poof* you've just thrown me into a new world; "Mommy this is
_confusing_! My window just split in two and half my text is hidden. I
don't know what to do!"

You're giving me too many options. You're making me think too much, forcing
me to make choices I don't care about.


>If that's not full-featured, I don't know what is.

Yes, exactly! It's not only full featured, it's _too_ full featured.


>>Well, from my point of view, it certainly can. As we discussed some
>>years ago Hrvoje, from my point of view (X)Emacs is a mere editor;
>
>I'm afraid I don't remember our previous discussions, [...]

It was a couple of years back during a discussion of the pros and cons of
adding the ability for XEmacs to natively use Perl as an extension language
in addition to Lisp. The last time I was experiencing opinions... :-)

We were talking of how you can view XEmacs in two distinct ways: as a mere
text editor; or as a Lisp interpreter with an exceptionally rich library,
some of which is uniquely suited to implement a text editor...

>From the text editor view, the ability to write extensions in a nother
language can be nothing but good, but from the Lisp interpeter view, adding
Perl into the mix can only dilute the value of it's core strengths (IMO, of
course). But lets not get into /that/ discussion here. :-)


>but I can certainly see your point here.  What I don't understand is
>why you keep using XEmacs.  Although Emacs is a decent editor, I'm
>sure there are ones as good, but without the "burden" of Lisp and
>programmability.

Probably for the very same reasons you use XEmacs. It's powerfull, it has
killer features, it's extensible, and no matter what you want to do, XEmacs
can probably do it. Mostly though, it can be summed up in one word:
"cperl-mode".

After trying about a million different editors, the only one that does Perl
half way decently is XEmacs. Nobody else even comes close (IMO, YMMV,
etc.).

Don't get me wrong, all my bellyaching isn't to suggest XEmacs is a bad
terrible editor. It's just that I think it could be even better.



>>So to improve the "manual" for /me/ you'd have to remove every
>>reference to lisp from it.
>
>I don't think the XEmacs manual makes all that many references to Lisp. 
>Have you actually read it?  Of course, by "manual" I don't mean the
>Lispref, but the actual XEmacs Reference Manual.

Yes, I read it. A long time ago, but...

The Lisp reference was just an example (possibly not a very good one). The
XEmacs User's Manual is a big huge weigthy tome of knowledge. The New Users
Guide is much better. Both do define the term "Buffer" and it's
relationship to "Files" and "Windows". And anything you want to do you can
probably figure out from these manuals. But then, since it has source
avilable and a license that allows it, I could have figured it out from
reading the source, given enough time, too.

My point isn't XEmacs´ inability to perform some task (really, it's
_Xemacs_ we're talking about here! Is there anything it /can't/ do? ;D) or
a lack of documentation. It's the accessability of it's features for
less-then-expert users.

The reason I don't know more about it is because I'm refusing to learn;
because the cost is too high. I don't need all the power of XEmacs, only a
small subset of it, and becoming an expert to use the small subset is a bad
tradeoff; too steep a price.

Very very few of the things I want to do with XEmacs should require me to
actually read the manual. They're simple things, why can't they be simple
to do?

My "other editor" allows me to work in the subset of functionality I'm
comfortable with while still keeping the more advanced features available.
It will gradually disclose more of it's secrets as you become more familiar
with it. That doesn't mean it's interface changes; it just means it doesn't
throw the advanced features up as barriers that you need to pass before you
can use the simple functions.

Keyboard equivalents are available, but not necessary. They are provided in
the menus for every command that has one, and in dialog buttons when the
buttons have one. In the latter case, the keyboard equivalents only become
available when you press the Mac OS standard "Command" key (more or less
equivalent to Ctrl on UN*X and Alt on `doze, I think) and after a short
delay. They don't get in your way by default, but when you start to get
comfortable and begin to explore they show up to provide you with a path to
ever more advanced features.

The search dialog pops up when you use the search command and lets you set
various search options. You can then press the Find button or the Find Next
button. It has options for searching multiple files on disk, with filter
criteria to include or exclude various files. It lets you turn on or off
regex searching etc and it provides both the search function and the
replace function.

The menus also contain commands to short-circuit the dialog, so when you
get tired of having that dialog in your face for each search, you can get
rid of it run the entire thing from the keyboard. But you're not required
to do so! You don't have to remember keyboard shortcuts until you're so
comfortable with them that it becomes easier for you, individually, to use
the keyboard instead.

In Xemacs I get thrown to the mini-buffer. A concept that's rather unique
to Emacs so no prior experience has prepared me for it. I have no frame of
reference to tell me how it works. It prompts with "I-search:". It tells me
nothing about what options are available to me at this point. It doesn't
tell me what it's doing, it offers no command keys and certainly no pretty
buttons to press. Pressing C-g (which someone once said worked kinda like
Ctrl-C or ESC in the rest of the world) doesn't bounce me out of it. It
returns me (apparently) to the last prefix that matched anything. "How the
hell do I get rid of this confusing thing that prevents me from working
with my file? It just keeps beeping at me!".

Using the "Replace" command works similarly. I manage until I've entered
the string to search for and the replacement string, but then what? Ok, it
sez to "f1 for help". Now there's a split window obscuring half of my file.
How do I get rid of that? And it doesn't offer options to "Yes, replace" or
"No, don't replace". It offers a huge array of keyboard shortcuts talking
about lotsa stuff I don't understand. What's "recursive edit"? What exactly
does "clear frame, redisplay, and offer same replacement again" do?
(Really, I couldn't figure this one out by experimenting!). Oh and why
doesn't it find any matches when I know the string is in there? Oh that's
right, it searches from point to EOF so I apparently have to scroll to BOT
before running the search...

Compare e.g. the search dialog in this screenshot
<URL:http://www.barebones.com/images/aqua_find_dialog.gif>.

For various reasons it doesn't do incremental search, but the general point
still stands. Putting a similar GUI on the search and replace functions
makes that feature accessible to non-expert users; and can be done without
impacting the experts that can work much faster using the mini-buffer.


But I'm not expert enough in human interaction design to really be
comfortable making this specific suggestions. I try to be vague on the
specifics intentionally for this reason. It's not that I have all the
answers for how to make XEmacs the perfect editor; I'm just trying to argue
that focusing on these issues -- instead of saying "Oh no, that would
jeopardize the power-user features and dumb down XEmacs" -- will lead to a
better editor for everyone involved.



>>Or maybe I just wish to redefine what is the "average" user of Emacs.
>>
>>Right now, as far as I can tell, the "average" user knows more then
>>average (if you'll pardon the pun) about lisp and the implementation
>>details of Emacs. There is a fairly large barrier to entry. When you
>>pass it it will scale upwards very well, but it doesn't scale _down_ at
>>all well. There is this huge gap between doing everything from the
>>menus and writing your own custom lisp bits to make Emacs behave the
>>way you want it to.
>
>I see your point, I really do, but I don't have a good idea how to fill
>this gap.  I think the tools like `M-x edmacro' (have you tried it? --
>`M-x edit-kbd-macro')

I dunno. What's it do? Where would I have found out about it's existence?
How do I work it? "M-x edmacro" just sez "no match" and "M-x
edit-kbd-macro" apparently expects me to know how it works before I try to
use it. It asks me for a keyboard macro to edit. I don't have any keyboard
macros do I? I never tried "Start Macro Recording". What's "C-x e, M-x, C-h
1, or keys" mean?


>We have a long way to go, and I'm not sure Emacs will ever fit the bill
>here.  Part of the problem is that, once you overcome the barrier, you
>are no longer part of the target group, and you even begin to *like* the
>way Emacs does things.  It seems like a tar pit, but I can't sympathize
>with that view and be entirely honest -- I've been assimilated.

I don't think it's hopeless. I _do_ like how XEmacs does things. It's just
that it's such a royal PITA to actually __figure_out__ how it does things.

All programmers face the problem that they know down to the last paren how
their program actually implements a given feature, but that doesn't mean
it's impossible for them to try to make th efeature more easy to use for
those that don't know it that intimately. For non-free software developers
this is pretty much a rock hard necessity because they can't tell users to
read the source; they've hidden it away and locked it up. If they can pull
it off, I'm damned sure y'all can too!




-- 
> ...publicity rights, moral rights, and rights against unfair competition..
Well, you've got me there.   I have no idea what any of those have to do with
SGML. Next you'll be claiming that running NSGMLS constitutes an unauthorized
public performance of SGML.                                  -- Richard Tobin

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Terje Bless <link@pobox.com> writes:

>>I'm not sure what you mean by "the buffer sub-menu", but in the
>>menubar, the "Buffers" menu contains a "Go to buffer..." item which
>>is marked with `C-x b' -- and that's how you switch buffers using
>>keyboard.
>
> I'm struggling with the limits of my Emacs vocabulary here, but I
> have the Buffers menu set up to group buffers by type (that "mode"
> rather, probably, no?) and to give each group of buffers their own
> sub menu.

As I said, so do I.

> The only command listed with a keyboard shortcut in my XEmacs is the
> "List All Buffers" command.

You're probably using the "Buffers Popup Menu" which pops up when you
right-click on the part of the mode line where the buffer name
resides.  I was talking about the "Buffers" menu on the menubar (the
top-level menu on the top of an XEmacs frame.)

The "Switch to Buffer" command could trivially be added to the popup
menu as well.

>>Pressing `C-x b <tab>' gives you a "completions" buffer
>
> And *poof* you've just thrown me into a new world; "Mommy this is
> _confusing_! My window just split in two and half my text is hidden. I
> don't know what to do!"
>
> You're giving me too many options. You're making me think too much,
> forcing me to make choices I don't care about.

Then keep using the menus and ignore my suggestions.  I merely tried
to help.

I have no desire to debate the rest of your message.  You were
unwilling to even try `edmacro' for long enough to get the point I was
trying to make.  You obviously use a different query-replace, one
whose help doesn't explain "Type Space or `y' to replace one match,
Delete or `n' to skip to next," at the very first line of output.  You
seem to be unwilling to study isearch for more than three seconds to
grasp why it makes more sense than a huge dialog box.

XEmacs has a lot of flaws, many of which can be fixed with appropriate
user input.  What you're providing is a mixture of complaints,
philosophy, and displays of stubborn refusal to learn about the things
that XEmacs *does* get right.  I wish I could ignore the parts I don't
care about and learn from your input, but I can't.  To paraphrase you,
you're giving me too much.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> Date: Sun, 21 Apr 2002 17:11:36 +0200
> From: Terje Bless <link@pobox.com>
> 
> >Pressing `C-x b <tab>' gives you a "completions" buffer
> 
> And *poof* you've just thrown me into a new world; "Mommy this is
> _confusing_! My window just split in two and half my text is hidden.

How is this different from a dialog that pops up and obscures part of
the display?

> I don't need all the power of XEmacs, only a
> small subset of it, and becoming an expert to use the small subset is a bad
> tradeoff; too steep a price.

If you refuse to learn, how do you know that you only need a small
subset of the features?  Perhaps if you learned more you'd want to use
more of them?

In general, there should be no need to read the entire Emacs manual,
or even large parts thereof (although this is certainly recommended!).
The manual should be indexed well enough to allow you to find any
important issue within seconds by using the `i' command.  If you
cannot find some issue via `i', I suggest to file a docs bug report.

> Very very few of the things I want to do with XEmacs should require me to
> actually read the manual. They're simple things, why can't they be simple
> to do?

Examples, please!  It is not useful to write slogans to which everyone
agrees without specific examples.  What are those ``simple things''
that cannot be done in a simple way?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Hrvoje Niksic wrote:
> Then keep using the menus and ignore my suggestions.  I merely tried
> to help.

I don't think that Terje meant to offend anyone.  He noticed that the Emacs 
developers were discussing the problems that new users have with the UI, and 
that the developers would like to know what specific problems new users 
actually have.  So he offered his two cents of real-world experience.

If the devlopers aren't interested in knowing why so many programmers these 
days are staying away from Emacs, then keep the UI problems and ignore Terje's 
suggestions.  He merely tried to help.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Michael" == Michael Toomim <toomim@cs.berkeley.edu> writes:

    Michael> If the devlopers aren't interested in knowing why so many
    Michael> programmers these days are staying away from Emacs, then
    Michael> keep the UI problems and ignore Terje's suggestions.  He
    Michael> merely tried to help.

We (and that includes Hrvoje, who has done far more than his share of
translating UI ideas into code) certainly are interested; but we'll be
much more interested if we can see ways to keep the (X)Emacs we love
while making it more accessible to those who wish to use it
differently.

If one wants to write code, nothing's going to stop it.  Write it,
submit it, and if it really meets Terje's criterion of "power under
the hood with a simple presentation", it's a shoo-in.  If one doesn't
want to write code, OK, just advocate, but remember it needs to be
done in a way that persuades somebody else to do it.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>>Date: Sun, 21 Apr 2002 17:11:36 +0200 From: Terje Bless
>><link@pobox.com>
>>
>>>Pressing `C-x b <tab>' gives you a "completions" buffer
>>
>>And *poof* you've just thrown me into a new world; "Mommy this is
>>_confusing_! My window just split in two and half my text is hidden.
>
>How is this different from a dialog that pops up and obscures part of
>the display?

All things being equal, it wouldn't be. Not by much anyway.

But in this there is the matter of what people are used to and expect. In a
graphical editor, popping up a dialog is the normal way to handle this. A
dialog also has some advantage that the split screen approach does not
have; chiefly that of following a stratageme of direct manipulation. You
don't have to weasel out what keys you can press to achieve something. All
the options that you need are avilable as clearly labelled text fields or
buttons.

But that's beside the point in this case. The dialog that pops up which I
gave as an example in a different message was as a front end for the search
and replace functions. Switching between buffers can be done either with a
dialog providing a list (but which variant C-x C-b handles well enough), or
by switching sequentially, or by any number of other variants. Nobody
suggested using one of these terrible newfangled dialog thingies for this!


>>I don't need all the power of XEmacs, only a small subset of it, and
>>becoming an expert to use the small subset is a bad tradeoff; too steep
>>a price.
>
>If you refuse to learn, how do you know that you only need a small
>subset of the features?  Perhaps if you learned more you'd want to use
>more of them?

I allready do want to use more of them, and to use those I allready use
more efficiently. But I have made a concious choice that the price of
admission is too high. I make do with what I have because I'm not willing
to pay the price of admission to get the rest of the features.

Trust me, when the the pain outweighs the price, I will learn. I'm just
suggesting that one way to achieve your stated goal of bringing XEmacs to a
wider audience is by lowering the price of admission. The alternative is to
make everyone rich enough to be able to afford it, and frankly I don't see
that as being very realistic!


>>Very very few of the things I want to do with XEmacs should require me
>>to actually read the manual. They're simple things, why can't they be
>>simple to do?
>
>Examples, please!  It is not useful to write slogans to which everyone
>agrees without specific examples.  What are those ``simple things'' that
>cannot be done in a simple way?

Ok. I'll try to come up with some specific suggestions and post them to
xemacs-beta. I haven't allredy done so because I'm not sufficiently
familiar with XEmacs to be able to differentiate well between what is
feasible and what isn't, what is worthwhile and what isn't. What I might be
able to provide is examples of what /I/ find difficult -- and sometimes
suggestions for ways it could be made easier -- and then leave the real
work (the thinking about ways to solve it and the implementation) up to the
developers.

I've deliberately avoided getting into specifics because quite frankly I'm
not _qualified_ to speak to them. The only people that are really qualified
to do that are the developers and very advanced users. I'm just trying to
provide general input for them to take into account when designing and
implementing XEmacs.


And please accept my apologies for not doing that any better...

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Terje" == Terje Bless <link@pobox.com> writes:

    Terje> Eli Zaretskii <eliz@is.elta.co.il> wrote:

    >> If you refuse to learn,

Many of the XEmacs developers who sympathize far more with you than he
does (or, to be honest, me) are being silent for various reasons.  So
don't take Eli's position as completely representative.  (And Eli isn't
an XEmacs developer, but I can't say how representative he is of the
emacs-devel crowd---note the cross-post.)

Note that in many cases at XEmacs all it takes is one supporter in the
core to get ideas implemented, too.  Even if Hrvoje and I publically
oppose suggestions, if Andy or Ben picks one up and decides to run
with it (== write code), it very likely gets in.

    Terje> I'm just suggesting that one way to achieve your stated
    Terje> goal of bringing XEmacs to a wider audience is by lowering
    Terje> the price of admission.

Right; I don't think anybody has missed that point.  But one of the
problems is that without more concrete suggestions it's hard to see
how this could be done.  It won't come for free; at the very minimum,
some of the doc writers and editors will have to change perspective, a
perspective which has historically been useful to the community.

And it may be that other compromises need to be made.  So please be
patient with us, too:  while we (as a group) may be far more expert
than you on internals and advanced usage, few of us have thought very
carefully about the kind of issues the changes you propose would
require.

Examples help.

    Terje> Ok. I'll try to come up with some specific suggestions and
    Terje> post them to xemacs-beta.

Please post them here, to xemacs-design, if they are intended as
examples of general fixes that should be made "in similar places where
appropriate".  If they are really bug reports, where a local fix would
be fine, then post to xemacs-beta.  At GNU Emacs, I guess the
appropriate channel is emacs-devel, check with Eli.

    Terje> I've deliberately avoided getting into specifics because
    Terje> quite frankly I'm not _qualified_ to speak to them.

But for the reasons mentioned above, nobody else is any more
qualified.

For example, consider Brady Montz's suggestion about adding xrefs to
sort-* to the sort-lines docstring.  While I oppose that particular
suggestion, it did lead to the constructive alternative of suggesting
the use of the idioms C-h a and C-h C-f in this context.  (And I could
change my mind, that was just my first take.)  Note how that focuses
the discussion far better than his original comment where he said
"there are too few cross-references" and I misinterpreted that as
"Brady rarely sees cross-references".

Nothing wrong with what he wrote in the first case, either.  Nor was
my interpretation implausible.  These issues are inherently hard to
tease out.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 22 Apr 2002, Stephen J. Turnbull wrote:

> >>>>> "Terje" == Terje Bless <link@pobox.com> writes:
> 
>     Terje> Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
>     >> If you refuse to learn,
> 
> Many of the XEmacs developers who sympathize far more with you than he
> does (or, to be honest, me) are being silent for various reasons.  So
> don't take Eli's position as completely representative.

No one's position should be taken as completely representative.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kai Großjohann]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Terje" == Terje Bless <link@pobox.com> writes:
>
>     Terje> Eli Zaretskii <eliz@is.elta.co.il> wrote:
>
>     >> If you refuse to learn,
>
> Many of the XEmacs developers who sympathize far more with you than he
> does (or, to be honest, me) are being silent for various reasons.

I think Eli is sympathizing with Terje.  Does "refuse" perhaps convey
a stronger meaning to a native English speaker than I thought at
first?

For me, Eli was simply saying: if you don't want to learn, you might
be missing something.  (I hope that "don't want" is less strong than
"refuse", so that my point comes across.)

kai
-- 
Silence is foo!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Stephen J. Turnbull <stephen@xemacs.org> wrote:

>These issues are inherently hard to tease out.

I think that as long as we all agree on this statement, we'll be fine no
matter where we end up. :-)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> I think Eli is sympathizing with Terje.  Does "refuse"
    Kai> perhaps convey a stronger meaning to a native English speaker
    Kai> than I thought at first?

Hm.  That hadn't occurred to me.  "Refuse to learn" in my dialect is
quite a strong condemnation, actually, and I was already adding quite
a bit of fuzz since Eli isn't (quite) a native speaker.  :-)  To
"refuse" to learn typically implies obstinacy or perversity.  In my
dialect, which I think is representative of native speakers in this
particular case.

My apologies, Eli, if I've gotten the connotations you intend quite
opposite.

Be that as it may, Eli is clearly arguing that the benefits to
learning more about Emacs IHHO greatly outweigh the barriers, enough
so that he's willing to contest Terje's (thought-out) opinion.
Furthermore, Eli implies that the cost of reducing the barriers is
quite high (elsewhere in the thread).

My point was that in XEmacs there are several developers who take the
opposite position (Andy, Ben, at least).  Despite (?) their
development experience, they feel the barriers are higher than the
benefits for a large potential audience, and that the cost to the
developers of reducing those barriers is low enough to be well worth
it.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

    Stephen> Hm.  That hadn't occurred to me.  "Refuse to learn" in my
    Stephen> dialect is quite a strong condemnation, actually, and I
    Stephen> was already adding quite a bit of fuzz since Eli isn't
    Stephen> (quite) a native speaker.  :-) To "refuse" to learn
    Stephen> typically implies obstinacy or perversity.  In my
    Stephen> dialect, which I think is representative of native
    Stephen> speakers in this particular case.

    Stephen> My apologies, Eli, if I've gotten the connotations you
    Stephen> intend quite opposite.

I see this last is quite unclear; it could be read to imply "Eli
condemns Terje", which is not my intention.

What I meant is that (1) I'm aware that Eli is not a native speaker,
(2) I do not believe he intends "condemnation" of Terje, but (3) I do
believe Eli feels strongly that Terje _should_ think again, and invest
more effort in learning about Emacs.  (4) If (3) is wrong, then I
really misread Eli quite badly, and I'm sorry.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kai Großjohann]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Be that as it may, Eli is clearly arguing that the benefits to
> learning more about Emacs IHHO greatly outweigh the barriers, enough
> so that he's willing to contest Terje's (thought-out) opinion.
> Furthermore, Eli implies that the cost of reducing the barriers is
> quite high (elsewhere in the thread).

There might be some misunderstandings here.  My reading of the whole
thing:

Terje: I just want to use a few Emacs features.  I don't want to
become an Emacs expert just to use these few features.

Eli: It's worth it to learn more Emacs features.

It appears that one is not an answer to the other.  Also, these two
statements don't contradict each other.  It should be very simple in
Emacs to do simple things, such as opening a file and moving the
cursor and inserting some characters and saving the file.

If something "simple" is not simple to do, that's a bug and should be
fixed.  For example, I believe that completion is a really great
thing but that file selector boxes would be helpful for the casual
user, so they should be added in Emacs¹; requiring casual users to
learn about the minibuffer prompt and TAB is not a good idea, IMVHO.

Of course, the challenge is to get a file selector box which allows
all the nifty completion things, too.  As that might be difficult,
one could offer traditional C-x C-f behavior in addition to the file
selector box.

kai

¹ I use "Emacs" to mean both flavors in the whole message, except
  here.  File selector boxes are already present in XEmacs.
-- 
Silence is foo!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stefan Monnier]

"Random" sampling:

> > Be that as it may, Eli is clearly arguing that the benefits to
> > learning more about Emacs IHHO greatly outweigh the barriers, enough
...
> There might be some misunderstandings here.  My reading of the whole
> thing:

Boy, people are so touchy !
Can we stop this meta discussion and get back to constructive arguments ?


	Stefan

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 23 Apr 2002, Stephen J. Turnbull wrote:

> >>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> 
>     Kai> I think Eli is sympathizing with Terje.  Does "refuse"
>     Kai> perhaps convey a stronger meaning to a native English speaker
>     Kai> than I thought at first?
> 
> Hm.  That hadn't occurred to me.  "Refuse to learn" in my dialect is
> quite a strong condemnation

I used ``refuse to learn'' because Terje literally said so in his message.  
Since it was (a kind of) a quote, I didn't consider it rude or offensive.
It wasn't a condemnation.

> My apologies, Eli, if I've gotten the connotations you intend quite
> opposite.

No sweat, misunderstandings happen all the time.

> Be that as it may, Eli is clearly arguing that the benefits to
> learning more about Emacs IHHO greatly outweigh the barriers, enough
> so that he's willing to contest Terje's (thought-out) opinion.

Well, yes and no.  Terje seemmed to say that he didn't want to read the 
manual, period.  Not even a single section, not even when in bad need of 
some specific information.  That sounds extreme to me: if there's a way 
of getting quickly to the necessary info, why should someone refuse to do 
that on purpose?

> Furthermore, Eli implies that the cost of reducing the barriers is
> quite high (elsewhere in the thread).

I guess this depends on your definition of ``quite high''.  In general, 
work on documentation requires a large effort, even just to keep the 
docs up-to-date.  It might, for example, tie up one or two dedicated 
volunteers full time.  Significant improvements in the documentation 
system of the type suggested in this thread will probably need more 
effort, IMO.

But that doesn't mean I object to such changes, just that I think people 
should be aware of the pitfals.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Kai Groþjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:

>"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>>>>>>>"Terje" == Terje Bless <link@pobox.com> writes:
>>
>>Terje> Eli Zaretskii <eliz@is.elta.co.il> wrote:
>>
>>>>If you refuse to learn,
>>
>>Many of the XEmacs developers who sympathize far more with you than he
>>does (or, to be honest, me) are being silent for various reasons.
>
>I think Eli is sympathizing with Terje.  Does "refuse" perhaps convey a
>stronger meaning to a native English speaker than I thought at first?
>
>For me, Eli was simply saying: if you don't want to learn, you might be
>missing something.  (I hope that "don't want" is less strong than
>"refuse", so that my point comes across.)

The connotations of the word "refuse" is probably what's causing the
confusion, yes. And it was, to be fair, me that used the word. cf. my other
message here.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Sun, 21 Apr 2002, Terje Bless wrote:

> >>>Pressing `C-x b <tab>' gives you a "completions" buffer
> >>
> >>And *poof* you've just thrown me into a new world; "Mommy this is
> >>_confusing_! My window just split in two and half my text is hidden.
> >
> >How is this different from a dialog that pops up and obscures part of
> >the display?
> 
> All things being equal, it wouldn't be. Not by much anyway.
> 
> But in this there is the matter of what people are used to and expect. In a
> graphical editor, popping up a dialog is the normal way to handle this.

I think you overestimate the power of old habits and underestimate the 
ability of people to learn new ones.  The completions buffer popping up 
might surprise someone the first time they see it (although Bash and tcsh 
users are probably used to that already), but in my experience 
(observing people who converted from Visual Studio etc.) it doesn't take 
more than a couple of times to get used to it.

> A
> dialog also has some advantage that the split screen approach does not
> have; chiefly that of following a stratageme of direct manipulation. You
> don't have to weasel out what keys you can press to achieve something. All
> the options that you need are avilable as clearly labelled text fields or
> buttons.

I hope you are aware that the completions popped up by Emacs are clickable.
Move your mouse pointer across the completions and observe the magic.

> I allready do want to use more of them, and to use those I allready use
> more efficiently. But I have made a concious choice that the price of
> admission is too high. I make do with what I have because I'm not willing
> to pay the price of admission to get the rest of the features.

I think you overestimate the price.  The price of using the Emacs manual 
as a reference, via the `i' command, is normally quite low.  (The 
abnormal cases usually constitute docs bugs.)  I suggest to try that, 
perhaps you will find it easier than you thought.

> Trust me, when the the pain outweighs the price, I will learn. I'm just
> suggesting that one way to achieve your stated goal of bringing XEmacs to a
> wider audience is by lowering the price of admission.

That's everobody's goal, I believe.  Specific examples and requests will 
help bring us closer to it.

> Ok. I'll try to come up with some specific suggestions and post them to
> xemacs-beta.

Thank you!

> I haven't allredy done so because I'm not sufficiently
> familiar with XEmacs to be able to differentiate well between what is
> feasible and what isn't, what is worthwhile and what isn't.

Don't worry about that; just tell what you find unclear, unobvious, 
cumbersome, etc.

> What I might be
> able to provide is examples of what /I/ find difficult -- and sometimes
> suggestions for ways it could be made easier -- and then leave the real
> work (the thinking about ways to solve it and the implementation) up to the
> developers.

Perfect!  Please do.

> And please accept my apologies for not doing that any better...

I don't see anything you should be apologizing for.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> The manual should be indexed well enough to allow you to find any
> important issue within seconds by using the `i' command.  If you
> cannot find some issue via `i', I suggest to file a docs bug report.

Come to think of it, why not automatically add clickable references from
doc-strings into the info manual?  That seems like it would be pretty
easy to do, since the necessary information is already there.

`Info-goto-emacs-command-node' already does something similar for
commands (though in a slightly less convenient way).  I don't know
whether the method Info-goto-emacs-command-node uses would be best for
doing all functions; maybe it would be better to just run a build-time
script that extracts the references from the .texi files and actually
embeds it into the doc-strings.

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

> Very very few of the things I want to do with XEmacs should require me to
> actually read the manual. They're simple things, why can't they be simple
> to do?

Right! This is exactly what I mean by working the way people expect. If
things work the way people expect then the cost of entry is small.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Kai Großjohann]

Terje Bless <link@pobox.com> writes:

> Hrvoje Niksic <hniksic@arsdigita.com> wrote:
>
>>Pressing `C-x b <tab>' gives you a "completions" buffer
>
> And *poof* you've just thrown me into a new world; "Mommy this is
> _confusing_! My window just split in two and half my text is hidden. I
> don't know what to do!"

What do you use to open files?

This is a genuine question.  I have the feeling that anyone who has
evern used TAB after C-x C-f will know what is going on, as the
completions feature is the same everywhere in Emacs.  But I learned
about TAB after C-x C-f in 1989 when using Jove, so my memory about
my own feelings after C-x b might well be wrong.  (In fact, I think
for some years I thought that C-x b isn't really useful, since I
could use C-x C-f with much the same effect: I came to the existing
buffer, at the same spot.  I recall thinking why is there C-x b if C-x
C-f is also fast?  This was still using Jove.)

kai
-- 
Silence is foo!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Michael" == Michael Toomim <toomim@cs.berkeley.edu> writes:

    Michael> Wait.. isn't this the whole point of this thread?  I
    Michael> thought this was about figuring out what what could be
    Michael> done to XEmacs to make it more mainstream -- to make it
    Michael> usable to those who haven't been assimilated?

No, it's not.  That's part of the point, but Ben enunciated the other
part (on xemacs-design, very early on)---helping Emacs to assimilate
more of those who could enjoy a mutually beneficial relationship with
Emacs.  To me, that's the important point ("here, little boy, wouldn't
you like a nice grape-flavor isearch?")  I grant that I'm probably in
a minority here, but please recognize my point of view.

    Michael> In my mind, the point behind this "the future of XEmacs"
    Michael> idea is to figure out how to generate a version (or
    Michael> dialect) of XEmacs that gives mainstream users access to
    Michael> the really cool functionality that XEmacs has to offer.

I think a lot of it would be easier to add to other editors.  Assuming
they're open source, of course.

    Michael> If we don't think that XEmacs can ever "fill the gap";
    Michael> that it can ever be useful to a user who isn't willing or
    Michael> prepared to go through the hazing ritual, then why are we
    Michael> even talking about this at all?

Besides the developer recruitment issue, many "modern UI concepts"
don't deserve that condescending epithet at all---they really are
useful!  We want them in our favorite editor.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Sun, 21 Apr 2002, Terje Bless wrote:

> I get by with C-x C-f, C-x C-s, C-s, and C-x C-c. I manage the occasional
> foray into Customize and instructions that say "put this in your .emacs".
> And the stuff in the Options menu makes my life ever so much easier.
> 
> But a lot of the time I'm hindered by the fact that Emacs insists on me
> adapting to it, instead of it adapting to me. It "DWIMs" fairly well in
> some situations, but a lot less well in others. And writing lisp code is
> considered an acceptable way to interact with Emacs for normal users!

A list of specific problems you have, in those situations where Emacs 
doesn't DWIM, would be nice.  It's hard to fix problems that are unnamed.

> But the real point of all this isn't any specific feature or implementation
> detail. The main point I'd like to make is that, again in my opinion, the
> single most important factor in making Emacs more accessible to more people
> is to start giving more weight to these issues (and, yes, as a consequence
> less weigth to other issues; it's a tradeoff when resources are limited).

I think this is already done.  That's why specific details are important: 
the tendency to make Emacs more usable is already there, but I have no 
doubt that more work is needed to actually make that happen.

> The perfect feature needs no documentation because it's intuitively obvious
> how it works.

This is only true for very simple features.  Powerful and flexible 
features are normally complicated enough to require some documentation, 
without which they are less useful than they could have been.

> But there is also a
> possibility that Emacs just isn't the tool for me. Perhaps it's too
> advanced a tool for my simple use and I should stay with less powerfull,
> but also more easy to understand tools. That's a valid point of view. I'd
> like to see Emacs cater to me also

That's what the menus and the tooltips are supposed to accomplish, I think.

> and I firmly believe it can do that
> without compromising away the power it has that more advanced users need.

I don't believe this is possible.  Simplicity and power do contradict to 
some degree.  I agree with the general tendency to not trade power for 
simplicity, but in practice, beyond a certain level, power comes at the 
expense of simplicity.  That's why other editors praised for their 
simplicity are much less powerful than Emacs.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 20 Apr 2002, Nix wrote:

> Bear in mind that the terminology is an API problem too: the terms
> `buffer', `window', `frame' and so on are in the Lisp layer of (X)Emacs
> and are used by Lisp code.

Not only the API, but the UI as well: there are commands such as 
find-file-other-window etc.

IMHO, such a ``terminology revolution'' just doesn't make sense.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Andy Piper <andyp@bea.com> writes:

> Well so is Windows, but the advantage is that everyone knows how it
> works - you can get up to speed quickly on an application because
> everything works the way you expect. I'm not saying dialog boxes
> aren't clumsy, inefficient etc, etc - but for a bunch of users its
> what they expect. So it seems to me the principle of least surprise
> applies here.

I'd like Emacs to exceed the users expectations, rather than just meet
them.

However, currently doesn't even meet the current standards for HCI,
and while I'm full of hot air, you are doing useful work towards that
goal.  So I'll shut up now.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

At 05:44 PM 4/20/2002 +0200, Per Abrahamsen wrote:
>I'd like Emacs to exceed the users expectations, rather than just meet
>them.
>
>However, currently doesn't even meet the current standards for HCI,
>and while I'm full of hot air, you are doing useful work towards that
>goal.  So I'll shut up now.

:)

Of course the other thing is that we already have an API for widgets as 
used by custom. Maybe we should consider extending it to support dialog boxes.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> However, currently doesn't even meet the current standards for HCI,
> and while I'm full of hot air, you are doing useful work towards
> that goal.  So I'll shut up now.

I assume HCI stands for "Human-Computer Interaction".  If so, what
standards are you referring to?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Hrvoje Niksic wrote:

>>However, currently doesn't even meet the current standards for HCI,
>>and while I'm full of hot air, you are doing useful work towards
>>that goal.  So I'll shut up now.
> 
> I assume HCI stands for "Human-Computer Interaction".  If so, what
> standards are you referring to?

Must be ISO-4294967296...

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Hrvoje Niksic <hniksic@arsdigita.com> writes:

> I assume HCI stands for "Human-Computer Interaction".

Yes.

> If so, what standards are you referring to?

The "current standards" are basically what most software do today,
i.e. what users expect, which means dialog boxes (and partly
formalized by CUA and the Apple style guide, but I'm not using
standard in that sense of the word).

However, the "current standards" change all the time, and it would be
more fun to try to reach the point they are moving towards, rather
than at the point where they used to be.

The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Crossmailed between emacs-devel and xemacs-design.

Andy Piper <andyp@bea.com> writes:

> However, we should provide dialog boxes if people do things in a gui
> way, 

Actually, I believe the trend in HCI research is to avoid or minimize
the use of dialog boxes.  They really _are_ in the way, also in a GUI.
This doesn't mean the current (X)Emacs interface is good, it certainly
isn't intuitive to a new user.

So I think we really ought to forget about dialog boxes, and instead
concentrate on making the minibuffer interface more accesible.

Here is some suggestions:

1. Put the minibuffer in the top by default.  It is more visible
   there, and users of MSIE or Mozilla (and apparently some modern
   IDE's) will not be surprised to find an input field there.

2. Add some strong visual clue (color, animation, whatever) when focus
   change to the minibuffer.  The toolbar should probably also change
   to "relevant" buttons for the action, and for those actions that
   are relevant, a 

3. Maybe even have a dialog box (!) pointing to the minibuffer when
   activating a menu entry that traditionally pop up a dialog.  The
   box should have an "OK" and a "Don't pop up next time" button.

3b Alternatively a "novice" mode, where an arrow point to minibuffer,
   and a tooltip like message explain what is going on.  Many games
   teach their UI in that way.  (What a cool way to organize the
   standard (X)Emacs tutorial!  But I digress).

Dialog boxes are so 1980's.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

At 12:01 PM 4/19/02 -0700, Brady Montz wrote:
>That's the impression I'd gotten. I haven't yet had the chance to take
>a look at it.
>
>Am I mistaken that the differences between gtk and other native
>graphics code is exposed to lisp? That is, the lisp widget library
>knows about them?

In general this is incorrect, the same lisp code works on Windows, GTK, 
Motif and Athena. However, its fair to say that some things are more fully 
implemented on some platforms than others.

Bill's comments about geometry managers while true for X-variants and Java 
do not apply to Windows. So I am pessmistic about attempts to push more of 
the work out to the widgets. I certainly do not believe that we should 
start using GTK etc on windows to solve this problem. I think Netscape's 6 
use of non-windows widgets is a disaster since it makes the application a) 
very bloated and b) not look like a windows app.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Andy Piper <andyp@bea.com> writes:

> At 12:01 PM 4/19/02 -0700, Brady Montz wrote:
> >That's the impression I'd gotten. I haven't yet had the chance to take
> >a look at it.
> >
> >Am I mistaken that the differences between gtk and other native
> >graphics code is exposed to lisp? That is, the lisp widget library
> >knows about them?
> 
> In general this is incorrect, the same lisp code works on Windows, GTK, Motif
> and Athena. However, its fair to say that some things are more fully
> implemented on some platforms than others.

OK.

> Bill's comments about geometry managers while true for X-variants
> and Java do not apply to Windows. So I am pessmistic about attempts
> to push more of the work out to the widgets. I certainly do not
> believe that we should start using GTK etc on windows to solve this
> problem. I think Netscape's 6 use of non-windows widgets is a
> disaster since it makes the application a) very bloated and b) not
> look like a windows app.

And then you get the laughable situation on MacOS X where mozilla
doesn't use the native widgets, but has a theme attempting to
duplicate their look and feel. Talk about duplicated effort!

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[William M. Perry]

Andy Piper <andyp@bea.com> writes:

> At 12:01 PM 4/19/02 -0700, Brady Montz wrote:
>>That's the impression I'd gotten. I haven't yet had the chance to take
>>a look at it.
>>
>>Am I mistaken that the differences between gtk and other native
>>graphics code is exposed to lisp? That is, the lisp widget library
>>knows about them?
>
> In general this is incorrect, the same lisp code works on Windows, GTK,
> Motif and Athena. However, its fair to say that some things are more
> fully implemented on some platforms than others.

I think brady is thinking of the lisp bindings for GTK - this is not the
same as the things that the widget code uses.  Those are implemented in C,
but with the GTK or GNOME builds, there is just glue code in C to call lisp
to create and manage the underlying widgets.

> Bill's comments about geometry managers while true for X-variants and
> Java do not apply to Windows.

Well, writing a simplistic geometry manager for windows would not be
difficult.  All we would really need is a standard horizontal or vertical
box stacking container.

-bp
-- 
Ceterum censeo vi esse delendam

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

At 09:27 AM 4/19/02 -0700, Brady Montz wrote:
>1. actual widgets, with an abstraction layer that allows a single lisp
>    spec of them to work on multiple backends - gtk, qt, cocoa,
>    vt100. This might restrict them to be fairly simple, but that's not
>    necessarily a bad thing. I think speedbar and customize are good
>    examples of us straining against the limits of text.

So we actually have this in XEmacs. Its not complete, it has rough edges, 
but its a start. It would be great if we could come up with a standard lisp 
API (common to both XEmacs and Emacs) for doing this sort of stuff. For 
instance this is the XEmacs search dialog:

(defun make-search-dialog ()
   "Popup a search dialog box."
   (interactive)
   (let ((parent (selected-frame)))
     (make-dialog-box
      'general
      :parent parent
      :title "Search"
      :spec
      (setq search-dialog
            (make-glyph
             `[layout
               :orientation horizontal :justify left
               ;; neither the following height/width nor the identical one
               ;; below should be necessary! (see below)
               :height 11 :width 40
               :border [string :data "Search"]
               :items
               ([layout :orientation vertical :justify left
                        :items
                        ([string :data "Search for:"]
                         [button :descriptor "Match Case"
                                 :style toggle
                                 :selected (not case-fold-search)
                                 :callback (setq case-fold-search
                                                 (not case-fold-search))]
                         [button :descriptor "Regular Expression"
                                 :style toggle
                                 :selected search-dialog-regexp
                                 :callback (setq search-dialog-regexp
                                                 (not search-dialog-regexp))]
                         [button :descriptor "Forwards"
                                 :style radio
                                 :selected search-dialog-direction
                                 :callback (setq search-dialog-direction t)]
                         [button :descriptor "Backwards"
                                 :style radio
                                 :selected (not search-dialog-direction)
                                 :callback (setq search-dialog-direction nil)]
                         )]
                [layout :orientation vertical :justify left
                        :items
                        ([edit-field :width 15 :descriptor "" :active t
                                     :face default :initial-focus t]
                         [button :width 10 :descriptor "Find Next"
                                 :callback-ex
                                 (lambda (image-instance event)
                                   (search-dialog-callback ,parent
                                                           image-instance
                                                           event))]
                         [button :width 10 :descriptor "Cancel"
                                 :callback-ex
                                 (lambda (image-instance event)
                                   (isearch-dehighlight)
                                   (delete-frame
                                    (event-channel event)))])])]))
      ;; neither this height/width nor the identical one above should
      ;; be necessary! (in fact, if you omit the one above, the layout
      ;; sizes itself correctly; but the frame as a whole doesn't use
      ;; the layout's size, as it should.)
      :properties '(height 11 width 40))))

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Brady Montz <bradym@balestra.org> wrote:

>3. we have a nice set of tools for managing which files/buffers you
>have open and how to switch between them: ibuffer, iswitchb, various
>things like desktop.el, speedbar, buffer-menu, ...

I've been using XEmacs for programming since the early nineties. I _still_
have no clue how to switch between buffers from the keyboard! I keep going
to the Buffers menu and selecting the one I want. In my "other editor" --
BBEdit on Mac OS X; solidly planted in GUI land -- I /can/ switch between
buffers from the keyboard.

Odd that, considering how "keyboard-oriented" XEmacs is, and how "GUI
oriented" BBEdit is...


And speaking of which, the thing that confused me most over the years was
the terminology. A "buffer" is a "document" and a "frame" is a "window"?
Why do I have to choose "New Frame" when what I /really/ want is a new
window? And I don't work with "buffers"; I work with "files" or
"documents". "Buffers" are something hardware /has/ or that I implement in
code, it's not something I work with day-to-day.


I think "fixing" these things would go a long way towards making XEmacs
more friendly to that great majority of people who do /not/ spend their
entire lives inside (X)Emacs. Then again, they might utterly break it for
those that do... :-)


-- 
By definition there is __no_way__ any problem can be my fault.  Any problems
you think you can find in my code are all in your imagination. If you continue
with such derranged imaginings then I may be forced to perform corrective
brain surgery... with an axe.                              -- Stephen Harris

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Richard Stallman]

       I can imagine something where functions not only have a doc string,
       but enough info for a more cleverly interactive browser/searcher
       than M-x apropos to easily find them (we may not need much more for
       that), easily connected to the customize options relating to that
       function, and ideally a mini-tutorial or example code for those
       functions/variables.

Could you spell out how this would look in practice?
(Would you like to help write it?)

    3. we have a nice set of tools for managing which files/buffers you
       have open and how to switch between them: ibuffer, iswitchb,
       various things like desktop.el, speedbar, buffer-menu, ...

       It might be good to settle on one or a few different ways of using
       all of these and making them more obvious for beginners. 

I more or less agree, but I think desktop.el does not really belong in
this category.

    My personal interests are (1) and (2). I've been swamped with work for
    the last few months, but I'm really wanting to be able to have an
    aquafied emacs for my mac.

We will include support for Mac toolkits if someone writes it clearly,
but do remember that MacOS tramples your freedom just like Windows.
Our goal is to replace proprietary software, not to enhance it.  So
instead of looking to make GNU Emacs enhance MacOS, we should look to
enhance GNU to replace MacOS.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Richard Stallman <rms@gnu.org> writes:

>        I can imagine something where functions not only have a doc string,
>        but enough info for a more cleverly interactive browser/searcher
>        than M-x apropos to easily find them (we may not need much more for
>        that), easily connected to the customize options relating to that
>        function, and ideally a mini-tutorial or example code for those
>        functions/variables.
> 
> Could you spell out how this would look in practice?
> (Would you like to help write it?)

Well, it could go different ways.

I guess there's three different parts to this:

1. I want to have more ways to find the name of a function, variable,
   or mode that does X. X could be something as specific as "sorts
   lines in a region" or as vague as "neat and added recently."

   For this, I'm thinking something similar to the various mechanisms
   people have come up recently for finding stuff on the web. A
   topical menu like yahoo is handy, likewise a clever searching
   algorithm like google's has its place. 

   For example, I often find functions by searching the lisp code for
   certain strings, or following the chain of functions/variables from
   a likely starting point, or searching through the info pages,
   searching through keymaps. Basically, grepping and reverse
   engineering. Could be a lot more automated.

2. Once I've found a reference to it (an info page, the doc string,
   the customize gunk), I want better cross referencing.

   We're not too far off here. A "see also" section to the doc strings
   could be nice. But, the interface for this cross referencing is
   cumbersome. I can fire up info, describe variable, customize in
   their own seperate ways, but it would be nicer for a beginner to
   presented with a single buffer with everything you might want to
   read or modify or use regarding that item. Maybe a composite page
   containing all of those (or links to them), or a webring sort of
   approach where the info page might have embedded buttons you could
   click to (a) see the source (b) see an example (c) see related
   functions, ...  Maybe even, ... ahem, a popup menu!

   Brainstorming here, it seems that emacs might also be able to
   deduce related functions and variables from scanning the code,
   doing something similar to a use-definition analysis. If function X
   uses global variable Y, it would be handy to know that.

3. I want demos or examples. For some things, just having a little
   sandbox buffer seeded with apropriate text would be nice. for
   example, the first time I started playing with python mode I had to
   find some example python code, open the info page, run through the
   list of key commands and fiddle. Could easily have a tuturorial.py
   which has nice comments like "move the cursor here and type C-c l"
   ala the emacs tutorial. Likewise, gnus might be a lot easier to
   figure out if it included a demo mode that let you read
   make-believe newsgroups and mail spools without fear of trashing
   your email, and those articles could contain more tutorial stuff
   "like hit space, now hit W w and watch this email word wrap"

   Obviously, demos/examples are very specific, and would probably be
   written by the code's authors or other interested parties. Having a
   nice support mechanism for this to make it as simple as possible,
   along with the consensus to move forward with it would help a lot
   though. Just as emacs has builtin support for finding and
   displaying info pages, we could have builtin support for finding
   and running demos/examples/samples/tutorials. But, a good tutorial
   requires thought and experience of someone who knows what the code
   can do.

   What would be totally sweet is if a demo could be hooked up with
   customize. Have one frame with my customize options, and another
   with my demo. change this option, rerun, change that, try again,
   etc.

And yes, I'd be happy to help write it.

>     My personal interests are (1) and (2). I've been swamped with work for
>     the last few months, but I'm really wanting to be able to have an
>     aquafied emacs for my mac.
> 
> We will include support for Mac toolkits if someone writes it clearly,
> but do remember that MacOS tramples your freedom just like Windows.
> Our goal is to replace proprietary software, not to enhance it.  So
> instead of looking to make GNU Emacs enhance MacOS, we should look to
> enhance GNU to replace MacOS.

Or how about using MacOS to enhance emacs? 

I have the deepest respect for the GNU project, and owe much to
it. But two comments.

First, until GNU is ready to replace MacOS (which may never happen), I
see benefit in improving all software. I don't personally believe that
enhancements are zero-sum.

Second, nothing wins people over like a cool toy. Much of the respect
I have for GNU started when I got hooked on emacs back in 89. Making
emacs as addictive to a new round of programmer mac users seems good
for recruitment.

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 20 Apr 2002, Brady Montz wrote:

>    For example, I often find functions by searching the lisp code for
>    certain strings, or following the chain of functions/variables from
>    a likely starting point, or searching through the info pages,
>    searching through keymaps. Basically, grepping and reverse
>    engineering. Could be a lot more automated.

Would be nice to have that, but it's a non-trivial project, I think.  The 
rules for such reverse engineering are most of the time fuzzy, so it's 
not easy to program.

> 2. Once I've found a reference to it (an info page, the doc string,
>    the customize gunk), I want better cross referencing.
> 
>    We're not too far off here. A "see also" section to the doc strings
>    could be nice.

Are you familiar with the cross-references in GNU Emacs doc strings?  
(I'm not sure if that feature exists in XEmacs.)  They are displayed in a 
different face, and you can click on them (or type RET with point on 
them) to follow the reference.  These references are used for related 
variables and functions and for showing the function's source, for 
example.

>    But, the interface for this cross referencing is
>    cumbersome. I can fire up info, describe variable, customize in
>    their own seperate ways, but it would be nicer for a beginner to
>    presented with a single buffer with everything you might want to
>    read or modify or use regarding that item.

I'm afraid ``everything'' would take so much space that users will be 
unwilling to wade through all that stuff...

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> > 2. Once I've found a reference to it (an info page, the doc string,
> >    the customize gunk), I want better cross referencing.
> > 
> >    We're not too far off here. A "see also" section to the doc strings
> >    could be nice.
> 
> Are you familiar with the cross-references in GNU Emacs doc strings?  
> (I'm not sure if that feature exists in XEmacs.)  They are displayed in a 
> different face, and you can click on them (or type RET with point on 
> them) to follow the reference.  These references are used for related 
> variables and functions and for showing the function's source, for 
> example.

Yeah, not too far off here. That is nice, but I've seen few docstrings
that make much use of it. 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:

[re cross-references in docstrings]

    Brady> Yeah, not too far off here. That is nice, but I've seen few
    Brady> docstrings that make much use of it.

Hm, I use them all the time.  My only complaint is that we only have
mouse bindings for them.  I'd like to be able to type RET on them.
Bonus points if C-x o TAB TAB RET Does The Right Thing.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:
> 
> [re cross-references in docstrings]
> 
>     Brady> Yeah, not too far off here. That is nice, but I've seen few
>     Brady> docstrings that make much use of it.
> 
> Hm, I use them all the time.  My only complaint is that we only have
> mouse bindings for them.  I'd like to be able to type RET on them.
> Bonus points if C-x o TAB TAB RET Does The Right Thing.

I didn't say you didn't use them. Just that I haven't seen many doc
strings that take much advantage of them for the "see also" purpose. 

Taking my running example of sort-lines, It's doc tells me about it's
config variable sort-fold-case, but I had to do a find-library sort
to look at the source to find out about sort-paragraphs, sort-pages,
sort-fields, ...

And, taking this example further, I've actually been wanting
sort-paragraphs for years but never enough or at the right time to
take the effort of looking for it. While I'm pleased with myself that
I'd finally found it, this is precisely the sort of thing I wish had
jumped out at me long ago.

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> Date: 22 Apr 2002 00:31:06 +0900
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
> [re cross-references in docstrings]
> 
>     Brady> Yeah, not too far off here. That is nice, but I've seen few
>     Brady> docstrings that make much use of it.
> 
> Hm, I use them all the time.  My only complaint is that we only have
> mouse bindings for them.  I'd like to be able to type RET on them.
> Bonus points if C-x o TAB TAB RET Does The Right Thing.

Both RET and TAB work in GNU Emacs 21 and do what you want.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> From: Brady Montz <bradym@balestra.org>
> Date: 21 Apr 2002 10:17:13 -0700
> 
> I didn't say you didn't use them. Just that I haven't seen many doc
> strings that take much advantage of them for the "see also" purpose. 

How about sending bug reports about the missing references?  Or even
suggesting what related functions/variables should be mentioned in
specific doc string?

> Taking my running example of sort-lines, It's doc tells me about it's
> config variable sort-fold-case, but I had to do a find-library sort
> to look at the source to find out about sort-paragraphs, sort-pages,
> sort-fields, ...

I think "C-h a sort-" would have told you that faster...

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:

    Brady> "Stephen J. Turnbull" <stephen@xemacs.org> writes:

    >> Hm, I use them all the time.  My only complaint is that we only
    >> have mouse bindings for them.  I'd like to be able to type RET
    >> on them.  Bonus points if C-x o TAB TAB RET Does The Right
    >> Thing.

    Brady> I didn't say you didn't use them. Just that I haven't seen
    Brady> many doc strings that take much advantage of them for the
    Brady> "see also" purpose.

    Brady> Taking my running example of sort-lines, It's doc tells me
    Brady> about it's config variable sort-fold-case, but I had to do

I would say that's exactly right for a docstring.

    Brady> a find-library sort to look at the source to find out about
    Brady> sort-paragraphs, sort-pages, sort-fields, ...

That may be what _you_ resorted to, but besides Eli's suggestion of
C-h a sort- RET, there's C-h C-f sort-lines RET (output appended
below; taller than you would get on a 80x24 TTY, but the line
containing "sort-paragraphs" would almost certainly appear).  My
conclusion is that we don't need to redo all the docstrings, but
rather to educate people better about the available help functions.

------------------------------------------------------------------------
     resulting expression looks like this:

          (sort-regexp-fields nil "^.*$" "\\<f\\w*\\>"
                              (region-beginning)
                              (region-end))

     If you call `sort-regexp-fields' interactively, it prompts for
     RECORD-REGEXP and KEY-REGEXP in the minibuffer.

 - Command: sort-lines reverse start end
     This command alphabetically sorts lines in the region between
     START and END.  If REVERSE is non-`nil', the sort is in reverse
     order.

 - Command: sort-paragraphs reverse start end
     This command alphabetically sorts paragraphs in the region between
     START and END.  If REVERSE is non-`nil', the sort is in reverse
     order.
------------------------------------------------------------------------

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:
> 
>     Brady> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
>     >> Hm, I use them all the time.  My only complaint is that we only
>     >> have mouse bindings for them.  I'd like to be able to type RET
>     >> on them.  Bonus points if C-x o TAB TAB RET Does The Right
>     >> Thing.
> 
>     Brady> I didn't say you didn't use them. Just that I haven't seen
>     Brady> many doc strings that take much advantage of them for the
>     Brady> "see also" purpose.
> 
>     Brady> Taking my running example of sort-lines, It's doc tells me
>     Brady> about it's config variable sort-fold-case, but I had to do
> 
> I would say that's exactly right for a docstring.

I agree.

>     Brady> a find-library sort to look at the source to find out about
>     Brady> sort-paragraphs, sort-pages, sort-fields, ...
> 
> That may be what _you_ resorted to, but besides Eli's suggestion of
> C-h a sort- RET, there's C-h C-f sort-lines RET (output appended
> below; taller than you would get on a 80x24 TTY, but the line
> containing "sort-paragraphs" would almost certainly appear).  My
> conclusion is that we don't need to redo all the docstrings, but
> rather to educate people better about the available help functions.

I don't think the doc strings need changing. When I piped in on this
thread, I viewed it as a thread about the UI, specifically for
beginers. I see very little in the UI which makes these various
options obvious, and the biggest single struggle I have helping emacs
beginners is helping them learn how to find out
information. Currently, people have suggested three ways to get to
sort-paragraph from sort-lines: open sort.el (my fallback approach),
apropos, or Info-elisp-ref, and putting xrefs in the doc strings.

Now, as for more xrefs in the docstring. Not good. Bad. For one thing,
they are too likely to get stale. For another, I think the
cross-referencing mechanism should be seperate from the little pieces
that are being referenced. I don't think it's a good interface if
there's a different way to get to the info node from the doc string
than vice versa. I don't think I ever suggested this, but I can see
why people might think that. My thinking more is that: I want xrefs,
docstrings have a few of those, but they don't do enough for that,
people writing those strings generally aren't putting xrefs in, and
that's probably for the best cause xrefs are something different.

Back to my example. So far, three people have suggested three
ways. First, not all of these ways work for every function (for
example, C-h C-f gnus just failed for me), nor for every situation
(for example, starting from a keybinding instead of a function name),
none of them are apparant from the UI (I can only judge from xemacs,
and the inability of the beginners I've known to find them).

Now, once I found sort-paragraph, it was a "duh I shoulda C-h a and
that would have found it." But the fact is that even after 14 years, I
hadn't ever seen it. And I know I've read the docs for sort-lines
multiple times. I don't think I'm unusually dense, and I've seen many
posts to various lists and newsgroups where people, even well known
long-time users, had been missing out on "easy to find" functionality.

One of the points from way back in this thread was that emacs isn't as
easy to use as it could be. I think things like this are one reason
why. Emacs can do a lot, and you can do most anything with it,
including finding out everything you want to about how it works. But
there's just this "friction" between emacs and the user, where things
that could be much more simple or obvious just require that extra bit
of work that can result in the user just not doing it.

-------

So, time to experiment with some code. I'd like to know any idioms
that people have for finding information. In particular, I'd like to
know the situations in which those idioms are used. For example,
knowing a fair bit about emacs, I generally start with my comfortable
turf which is a known similar function, then I apropos, search the
info pages or source, or a known phrase (generally with nice emacs
terms like buffers, regions, yank, that are stirring up so much
trouble elsewhere on this thread :)), and I google search. The more
familiar I am with a package, the less likely I am to start with the
info pages or menus.

Probably shouldn't email those suggestions on this thread. I'm keeping
this reply on this thread, but any replies to that last query should
probably go on their own thread or straight to me.

I think I'm viewing the documentation as a bit of a graph, with nodes
being what you know or where you are. Examples: the function name, the
key command, the phrase describing what you want, the info node, the
main source file for the package, a menu entry, the customize
page. And there's ways to get from each to the other. Which paths are
most common, which are the most useful, and which entry points are
most likely?

With any luck, an interactive tutorial similar to the ones they gave
me back in grade school about how to find stuff in the library will
suffice. 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> From: Brady Montz <bradym@balestra.org>
> Date: 22 Apr 2002 09:54:09 -0700
> 
> I see very little in the UI which makes these various
> options obvious, and the biggest single struggle I have helping emacs
> beginners is helping them learn how to find out
> information. Currently, people have suggested three ways to get to
> sort-paragraph from sort-lines: open sort.el (my fallback approach),
> apropos, or Info-elisp-ref, and putting xrefs in the doc strings.

These all (and more) are under "Help" in the menu bar.

If you are saying the the menu bar is not obvious enough, then please
suggest practical ways to make that more obvious.  The problem with
help functions is that, IMO, a user should generally request help
explicitly, or make some sign that she needs help.  Otherwise, if we
stick the help info into her face when it is not requested, we risk
ending up with the equivalent of that annoying MSWord-style paper
clip.  So if the menu bar is not enough, please suggest the ways Emacs
should use to decide that the user needs help (and perhaps what kind
of help as well).

> Now, as for more xrefs in the docstring. Not good. Bad. For one thing,
> they are too likely to get stale.

I think documentation runs the risk of becoming stale no matter how
you organize it--separate from the stuff it refers to or not.  You
cannot avoid the maintenance burden here.

> Back to my example. So far, three people have suggested three
> ways. First, not all of these ways work for every function (for
> example, C-h C-f gnus just failed for me)

Is "C-h C-f" supposed to show the Info node for a command you type?
If so, the equivalent command works for me in Emacs with gnus.

> nor for every situation
> (for example, starting from a keybinding instead of a function name)

"C-h K" does that for me in Emacs.

> none of them are apparant from the UI

Help->More Manuals->Find Key in Manual and Find Command in Manual do
that in Emacs.

> So, time to experiment with some code. I'd like to know any idioms
> that people have for finding information. In particular, I'd like to
> know the situations in which those idioms are used.

It depends on what you are looking for, I think.  If the goal is to
find quickly a description of some subject, then a keyword-based
search (a user types several keywords, and Emacs finds the appropriate
documentation) is IMHO the best.  The `i' command in Info gets pretty
close to that (it's normally the first or second method I try when
looking for things).

This could be inappropriate for people who want an introduction to
some broad issue, though.

Another idea is to try the hierarchical approach: a user is asked a
series of questions about the subject she wants to read about, which
(the questions) progress from general to more and more specific, until
the subject is determined and its documentation displayed.  With each
question, the user is given a small number (like 4) of possible
responses that should narrow the search in the next stage.  Some
knowledge bases on the net are organized in such ways.

> For example,
> knowing a fair bit about emacs, I generally start with my comfortable
> turf which is a known similar function, then I apropos, search the
> info pages or source, or a known phrase (generally with nice emacs
> terms like buffers, regions, yank, that are stirring up so much
> trouble elsewhere on this thread :)), and I google search.

A suggestion for a procedure that uses Emacs facilities in a certain
order (derived from experience) can be found in the node "Help" of
the latest Emacs user manual (shipped with Emacs 21.1).

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: Brady Montz <bradym@balestra.org>
> > Date: 22 Apr 2002 09:54:09 -0700
> > 
> > I see very little in the UI which makes these various
> > options obvious, and the biggest single struggle I have helping emacs
> > beginners is helping them learn how to find out
> > information. Currently, people have suggested three ways to get to
> > sort-paragraph from sort-lines: open sort.el (my fallback approach),
> > apropos, or Info-elisp-ref, and putting xrefs in the doc strings.
> 
> These all (and more) are under "Help" in the menu bar.
> 
> If you are saying the the menu bar is not obvious enough, then please
> suggest practical ways to make that more obvious.  The problem with
> help functions is that, IMO, a user should generally request help
> explicitly, or make some sign that she needs help.  Otherwise, if we
> stick the help info into her face when it is not requested, we risk
> ending up with the equivalent of that annoying MSWord-style paper
> clip.  So if the menu bar is not enough, please suggest the ways Emacs
> should use to decide that the user needs help (and perhaps what kind
> of help as well).

Yes, can't have clippy. I much prefer a passive approach where
everything is unobtrusively at your fingertips over clippy's obtrusive
sticking fingers in your eyeball.

As for the menu bar, I don't know what emacs 21's looks like. since I
moved to xemacs back when emacs was at 19. 

I don't think that, for this particular scenario, the xemacs help menu
bar is at all obvious. Asside from the terminology issues (will a
novice understand the difference between lookup command and lookup
function, and "apropos" is the epitome of obscure) which is being
covered elsewhere, it's certainly not obvious to me which of those
menu items is the best thing to select to show me what's similar to
the command I currently have open in a help buffer.

For this particular example, a popup menu of common "what you might
want to see after reading this help text" actions might be the best
menu modification. 

I dislike relying on having things like only in a menu though, since
it's not obvious to right-click when you want "more." A little "click
here for more" button is more to my liking.

> > Back to my example. So far, three people have suggested three
> > ways. First, not all of these ways work for every function (for
> > example, C-h C-f gnus just failed for me)
> 
> Is "C-h C-f" supposed to show the Info node for a command you type?
> If so, the equivalent command works for me in Emacs with gnus.

Yeah. I was referring to Stephen's usage of that. 

Doesn't work on my xemacs installation, so it's probably just an
install issue.

> 
> > nor for every situation
> > (for example, starting from a keybinding instead of a function name)
> 
> "C-h K" does that for me in Emacs.

Exactly. My point which you responded to was that for my example
(sort-lines), the three (maybe four) methods people gave for getting
the list of related commands don't work in all situations. For the
related situation where you know the key command but not the name, you
need yet another method (C-h k, followed by some others).

So, we have a situation where there's approx. 14 useful C-h commands
worthy of mention in the xemacs help menu, and I don't think it's
immediately obvious which to use when (oh, I know the key so I use C-h
k. I want the related functions and because this function is nicely
named C-h a will probably do the trick. I want a general overview and
this is a stable core function so the info page is probably good let's
try C-h C-f, this really should be in the info index so let's get to
that with C-h i, this is a function so C-h f, no wait it's a variable
C-h v, dammit I just want the key binding so C-h w).

Help shouldn't require help.

Here's what I'm starting to come to after this discussion - I'd like
an abstraction layer or interface between me and the
help/configuration systems. Not a wizard, but a unified interface that
wouldn't require a wizard.

I think we already have all the info we need in the various docs and
source code, and most of the functionality is already there. It's a
matter of presenting more efficient interface to it all.

> > none of them are apparant from the UI
> 
> Help->More Manuals->Find Key in Manual and Find Command in Manual do
> that in Emacs.

Just because they are in the menu does not mean that it's apparant to
the user than when he's reading about sort-lines in a help buffer, he
should select those items to find out about related commands.

It is reasonable expect a user to figure out that the "find command in
manual" might do that (but only for things with an info page). I don't
see anything in the interface of that help buffer pointing me to
that. The menu bar is about the furthest thing from my mind while
reading that text. It's out of band.

> > So, time to experiment with some code. I'd like to know any idioms
> > that people have for finding information. In particular, I'd like to
> > know the situations in which those idioms are used.
> 
> It depends on what you are looking for, I think.  If the goal is to
> find quickly a description of some subject, then a keyword-based
> search (a user types several keywords, and Emacs finds the appropriate
> documentation) is IMHO the best.  The `i' command in Info gets pretty
> close to that (it's normally the first or second method I try when
> looking for things).

I'm thinking a better search mechanism would be really nice. Just
having better searching of the info pages would be huge.

> This could be inappropriate for people who want an introduction to
> some broad issue, though.
> 
> Another idea is to try the hierarchical approach: a user is asked a
> series of questions about the subject she wants to read about, which
> (the questions) progress from general to more and more specific, until
> the subject is determined and its documentation displayed.  With each
> question, the user is given a small number (like 4) of possible
> responses that should narrow the search in the next stage.  Some
> knowledge bases on the net are organized in such ways.

Yeah, I'm not so sure about that one though. I've never found those to
be particularly useful. I think the info pages do a nice job for
that. Just prefix each item or section with a "I want to" or "what is
a" and it seems it's about as close as we could hope to get.

There might be some really nifty knowledge base lisp engines out there
that we could benefit from though.

> > For example,
> > knowing a fair bit about emacs, I generally start with my comfortable
> > turf which is a known similar function, then I apropos, search the
> > info pages or source, or a known phrase (generally with nice emacs
> > terms like buffers, regions, yank, that are stirring up so much
> > trouble elsewhere on this thread :)), and I google search.
> 
> A suggestion for a procedure that uses Emacs facilities in a certain
> order (derived from experience) can be found in the node "Help" of
> the latest Emacs user manual (shipped with Emacs 21.1).

I'll check that out.

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:

    Brady> For this particular example, a popup menu of common "what
    Brady> you might want to see after reading this help text" actions
    Brady> might be the best menu modification.

Algorithm?  Or are we going to have to rely on massive effort from
volunteers?  :-)

    Brady> I dislike relying on having things like only in a menu
    Brady> though, since it's not obvious to right-click when you want
    Brady> "more." A little "click here for more" button is more to my
    Brady> liking.

But more what?  Does that mean go from the docstring to Info page (and
should that be the User Guide or the Lispref?), or the mode's keymap
wallpaper, or the mode docstring, or hyperapropos, or Info index?  Or
(dare I say it?) help-on-help?

I think one problem is that most of the people working on (X)Emacs cut
their teeth on permuted indicies, man -k, apropos, whatis, etc
commands.  Possibly if `C-h a' were glossed "search for functions (and
variables) with similar names" instead of "apropos"?  (Would "Names
like ... (C-h a)" do it?)

    >> Is "C-h C-f" supposed to show the Info node for a command you
    >> type?  If so, the equivalent command works for me in Emacs with
    >> gnus.

    Brady> Doesn't work on my xemacs installation, so it's probably
    Brady> just an install issue.

Gnus is bundled with Emacs.  I wonder if Eli would get the same
results on an unbundled package.  I'm pretty sure that's why we don't
pick it up.

    Brady> Help shouldn't require help.

Have you ever tried to use Windows help?

I have _never_ used Windows for anything other than sanity-check
Cygwin builds of XEmacs and that wonderful doc2txt utility that MS
Office provides.  But I'm better at navigating Windows help than any
of the Windows users I know -- if they don't understand, they ask; if
they don't get a useful answer, they give up or look in the deadtree
manual.

I'm afraid that "help shouldn't require help" is just wishful thinking.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 22 Apr 2002, Brady Montz wrote:

> I don't think that, for this particular scenario, the xemacs help menu
> bar is at all obvious. Asside from the terminology issues (will a
> novice understand the difference between lookup command and lookup
> function, and "apropos" is the epitome of obscure)

Emacs has tooltips for menu items, and the Help menu uses that heavily to 
help the novice.  It's not easy to get the help text right, and did take 
a few iterations, but at least you have a larger place to cram some 
descriptive text into than just the menu item itself.

> which is being
> covered elsewhere, it's certainly not obvious to me which of those
> menu items is the best thing to select to show me what's similar to
> the command I currently have open in a help buffer.

If the Help menu items aren't obvious, their text or organization (or 
both) should be improved, IMHO.

> For this particular example, a popup menu of common "what you might
> want to see after reading this help text" actions might be the best
> menu modification. 

I second Stephen's question: Algorithm?  The idea is very nice, and I'm 
sure many of us played with it, but it's hard to come up with a viable 
implementation.  If you can suggest a practical solution, please do.

> I dislike relying on having things like only in a menu though, since
> it's not obvious to right-click when you want "more." A little "click
> here for more" button is more to my liking.

Tooltips can help here as well.  In Emacs, we try to put on every 
clickable part of the display a tooltip that tells about mouse-2's 
action, since many users don't know about mouse-2.

> > > nor for every situation
> > > (for example, starting from a keybinding instead of a function name)
> > 
> > "C-h K" does that for me in Emacs.
> 
> Exactly. My point which you responded to was that for my example
> (sort-lines), the three (maybe four) methods people gave for getting
> the list of related commands don't work in all situations. For the
> related situation where you know the key command but not the name, you
> need yet another method (C-h k, followed by some others).

The manual is the place where all of these come together.  The single 
command `i' will find a function, a key, a variable, and a subject (like 
"paste").

The other help commands exist because they are more efficient when you 
know better what you are looking for.

> So, we have a situation where there's approx. 14 useful C-h commands
> worthy of mention in the xemacs help menu, and I don't think it's
> immediately obvious which to use when (oh, I know the key so I use C-h
> k. I want the related functions and because this function is nicely
> named C-h a will probably do the trick. I want a general overview and
> this is a stable core function so the info page is probably good let's
> try C-h C-f, this really should be in the info index so let's get to
> that with C-h i, this is a function so C-h f, no wait it's a variable
> C-h v, dammit I just want the key binding so C-h w).

Try `i' in the Info manual.  (Perhaps we should have an example to make 
this less abstract.)

> > It depends on what you are looking for, I think.  If the goal is to
> > find quickly a description of some subject, then a keyword-based
> > search (a user types several keywords, and Emacs finds the appropriate
> > documentation) is IMHO the best.  The `i' command in Info gets pretty
> > close to that (it's normally the first or second method I try when
> > looking for things).
> 
> I'm thinking a better search mechanism would be really nice. Just
> having better searching of the info pages would be huge.

I agree in principle, but please tell what kind of better search do you 
have in mind.  Most kinds I can think of need additional information that 
someone will have to supply, information that isn't in the text of the 
manual or in the doc strings.

> > Another idea is to try the hierarchical approach: a user is asked a
> > series of questions about the subject she wants to read about, which
> > (the questions) progress from general to more and more specific, until
> > the subject is determined and its documentation displayed.
> 
> Yeah, I'm not so sure about that one though. I've never found those to
> be particularly useful.

Try the HP site where they give advice about troubleshooting printer 
problems (don't have the URL handy, sorry).  When done right, that's a 
very powerful and useful technique.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On 23 Apr 2002, Stephen J. Turnbull wrote:

>     >> Is "C-h C-f" supposed to show the Info node for a command you
>     >> type?  If so, the equivalent command works for me in Emacs with
>     >> gnus.
> 
>     Brady> Doesn't work on my xemacs installation, so it's probably
>     Brady> just an install issue.
> 
> Gnus is bundled with Emacs.  I wonder if Eli would get the same
> results on an unbundled package.  I'm pretty sure that's why we don't
> pick it up.

I don't have an unbundled Gnus to try.  However, "C-h F" (which I 
understand is the Emacs equivalent of "C-h C-f") works by looking up the 
function in the indices of the Info manual associated with the function 
whose name you type.  So what is important for it is that the Info manual 
for Gnus is installed in a location that Emacs can find via INFOPATH or in
the default places, like /usr/local/info etc.

In other words, if you can say "C-h i d m gnus RET" and get the right 
version of the Gnus manual, then "C-h C-f" should have had no problems, 
either.  Unless "C-h C-f" works differently in XEmacs, that is.

>     Brady> Help shouldn't require help.
> 
> Have you ever tried to use Windows help?

IMHO, Windows ``help'' is awful, mostly because its contents is not 
useful.  They tell you the obvious things (``to open a file, click "File" 
and select "Open"'') in so many words, but the _really_ important issues, 
like how to solve problems, are nowhere to be found.  I think the info is 
simply not there, not surprisingly.

We shouldn't consider the Windows help as a good example in this 
discussion, I think.  With all its deficiencies and lots of possible 
improvements, the Emacs documentation system is miles ahead of what 
Windows gives me.  YMMV, of course.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:
> 
>     Brady> For this particular example, a popup menu of common "what
>     Brady> you might want to see after reading this help text" actions
>     Brady> might be the best menu modification.
> 
> Algorithm?  Or are we going to have to rely on massive effort from
> volunteers?  :-)

Heh, being a developer and not a manager, I'll always pick the
algorithm when possible :).

>     Brady> I dislike relying on having things like only in a menu
>     Brady> though, since it's not obvious to right-click when you want
>     Brady> "more." A little "click here for more" button is more to my
>     Brady> liking.
> 
> But more what?  Does that mean go from the docstring to Info page (and
> should that be the User Guide or the Lispref?), or the mode's keymap
> wallpaper, or the mode docstring, or hyperapropos, or Info index?  Or
> (dare I say it?) help-on-help?

Sounds like a good start to me. Keeping in mind the 90/10 rule, I'm
still happy with an interface with better cross-referencing between
these various "doc domains." 

For example, I have no beef using a web site that has a dictionary
cross refernced with a thesaurus with an encyclopedia. People
understand that sometimes you have to skip around. I just want the
skipping around to be as easy as possible. 

I think that having links between the various doc sources that we
already have and know about which are immediately apparant to the user
would nicely take care of the 90% case. 

As I've said many times before, in the cross referencing case we
already have the most of the info we need, and are largely there. If
we only automate/unify what experienced users do by habit (here I do
C-h a, then I select that and do a C-h f, now I select that and do a
find-library, ...) that would be a nice improvement.

Then, when could consider more exotic brainstormy stuff like dropping
in a googly search mechanism for the info pages, or (something I would
love) "check this out" lists for functions added or changed since
(x)emacs version xx.yy.zz, etc.

> I think one problem is that most of the people working on (X)Emacs cut
> their teeth on permuted indicies, man -k, apropos, whatis, etc
> commands.  Possibly if `C-h a' were glossed "search for functions (and
> variables) with similar names" instead of "apropos"?  (Would "Names
> like ... (C-h a)" do it?)

Yeah. As has been hashed in the vocabulary portion of this thread,
emacs has an, um, unusual linguistic heritage compared to many of the
newer users. I really have no opinion about what to do about that, but
lean towards the glossary approach. Gotta call these things something,
and nothing picked will be obvious to everyone.

But, as much as I like "apropos" I imagine people might be happier
with something else. sigh.

>     Brady> Help shouldn't require help.
> 
> Have you ever tried to use Windows help?
> 
> I have _never_ used Windows for anything other than sanity-check
> Cygwin builds of XEmacs and that wonderful doc2txt utility that MS
> Office provides.  But I'm better at navigating Windows help than any
> of the Windows users I know -- if they don't understand, they ask; if
> they don't get a useful answer, they give up or look in the deadtree
> manual.
> 
> I'm afraid that "help shouldn't require help" is just wishful thinking.

I can't even imagine that windows help is something we can even
compare to. That is such a useless pile. 

However, I have found MSDN, especially the newer content which appears
to have a higher quality standard, to be very useful though. I've
satisfied 90% of my windows API questions by wandering about there,
and have learned lots of unasked for but very useful stuff along the
way. Plopping into a contract at microsoft with absolutely no windows
experience (sympathies please), once pointed towards MSDN I found it
needed no help at all. And, at least the stuff I've been talking about
(functions, variables, generic API sorta stuff), is a very similar
problem to what MSDN was designed for. And, I've been assuming the
users, while emacs novices, are not computer novices.

I see emacs as primarily a programmer's editor, not a word
processor. If we are to model after anything, we should model after
what programmers are used to. For that reason, I don't think things
like "apropos" were a bad choice. But it is an increasingly archaic
one.

To chime in on "buffers" - programmers know what buffers are, they know
that words that programs use have funny meanings, and they know you
gotta use a glossary sometimes. So, I don't see any need to change
that terminology.

But, programmers are used to things like MSDN, man pages, and howtos,
so looking at them isn't a bad thing.

Back to your point, yes "help shouldn't require help" might be just
wishful thinking. How about "help should require minimal help?"

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Stephen J. Turnbull]

>>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:

    Brady> "Stephen J. Turnbull" <stephen@xemacs.org> writes:

    >> But more what?  Does that mean go from the docstring to Info
    >> page (and should that be the User Guide or the Lispref?), or
    >> the mode's keymap wallpaper, or the mode docstring, or
    >> hyperapropos, or Info index?  Or (dare I say it?) help-on-help?

    Brady> Sounds like a good start to me.

But describing it took 5 lines, and putting in the xrefs themselves
won't be much less ... many docstrings are two or three.  Overkill, I
think, and pretty quickly very annoying.

TBH, I don't see the kind of concrete example/suggestion here that I
could take and run with, not yet.

    Brady> However, I have found MSDN, especially the newer content
    Brady> which appears to have a higher quality standard, to be very
    Brady> useful though. I've satisfied 90% of my windows API
    Brady> questions by wandering about there, and have learned lots
    Brady> of unasked for but very useful stuff along the way.

This is exactly what Eli and I recommend that you do with the Emacs
docs ... wander about.  Hm.  I see some difference between Emacs and
Windows, but enough similarity in scale and scope to justify the
analogy.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Brady" == Brady Montz <bradym@balestra.org> writes:
> 
>     Brady> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
>     >> But more what?  Does that mean go from the docstring to Info
>     >> page (and should that be the User Guide or the Lispref?), or
>     >> the mode's keymap wallpaper, or the mode docstring, or
>     >> hyperapropos, or Info index?  Or (dare I say it?) help-on-help?
> 
>     Brady> Sounds like a good start to me.
> 
> But describing it took 5 lines, and putting in the xrefs themselves
> won't be much less ... many docstrings are two or three.  Overkill, I
> think, and pretty quickly very annoying.
> 
> TBH, I don't see the kind of concrete example/suggestion here that I
> could take and run with, not yet.

I would personally be quite happy with the concrete suggestion I made of a
single, uniform browsing interface where I can trivially get from one
piece of documentation to another. The analogy I used was a web-ring.
So, how about a doc-ring between:

1. the info node
2. the source
3. an example/howto
4. the docstring
5. the key binding
6. the mode or greater package a command is in
7. related commands/variables (by name, location, explicitly listed by
   a doc writer, whatever).
8. the customize page
9. home pages of packages (like gnus's home page).

With uniform programming and user interfaces it should be
extendable. If someone writes something that can handle a "I want to
capitalize a paragraph" request, he should be able to plug it in. If
someone else writes something that finds in your init files where the
variable you're looking up was set, that might be something people
would want.

Given any of those, I want to be able to, with a single fluid click or
flick of my eye, be able to find as many of the others as
possible. More importantly, I want my friends and roommate to be able
to, so they'll stop struggling and pestering me, and start using emacs
effectively.

The main problem they seem to have is that they discover a few of that
list (1, 4 mainly), and only after weeks of struggle before they ask
me do they find out about the others. "Oh, C-h m, that's cool! I wish
I'd known about that sooner."

Examples, in particular, are hard to find. That might be another issue
altogether.

I'm wondering about the fixation on xrefs within the docstrings. It
could be from the desire to drill down on a specific example, but I'm
wondering if there's been a miscommunication. My primary interest is
in better xrefs between the doc domains, rather than within
them. Improving the first would probably help the second though.

For example, I'm editing a C++ file. What's the simplest way for me to
pull up the info docs on the current major and minor modes? What's the
quickest way to get a list of the configuration options affecting
them? The quickest way to set them? Are there any minor modes people
commonly use with C++ files that I'm not using? I think that the last
would require some extra doc-writing, but the others could be handled
by a better interface guiding the user from one thing (say, the output
of C-h m) to the next (the info page for each mode in there, or the
appropirate customize pages).

I'll try to get a rough draft of this in the next few weeks, when I can
tear myself away from MSDN :).

>     Brady> However, I have found MSDN, especially the newer content
>     Brady> which appears to have a higher quality standard, to be very
>     Brady> useful though. I've satisfied 90% of my windows API
>     Brady> questions by wandering about there, and have learned lots
>     Brady> of unasked for but very useful stuff along the way.
> 
> This is exactly what Eli and I recommend that you do with the Emacs
> docs ... wander about.  Hm.  I see some difference between Emacs and
> Windows, but enough similarity in scale and scope to justify the
> analogy.

Wandering is a good recommendation. My recommendation is to find a way
to make this easy for beginners. Most of my attempts to get beginners
to wander through the emacs realm result in them becoming irritated
with the interface it provides to do so, and they generally bail. That is
my main point, and thrust of my examples. As for how to do this, I
only have suggestions. 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

> From: Brady Montz <bradym@balestra.org>
> Date: 23 Apr 2002 11:20:43 -0700
> 
> 
> So, how about a doc-ring between:
> 
> 1. the info node
> 2. the source
> 3. an example/howto
> 4. the docstring
> 5. the key binding
> 6. the mode or greater package a command is in
> 7. related commands/variables (by name, location, explicitly listed by
>    a doc writer, whatever).
> 8. the customize page
> 9. home pages of packages (like gnus's home page).

Sounds good, but how does a user get into the ring in the first place?

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: Brady Montz <bradym@balestra.org>
> > Date: 23 Apr 2002 11:20:43 -0700
> > 
> > 
> > So, how about a doc-ring between:
> > 
> > 1. the info node
> > 2. the source
> > 3. an example/howto
> > 4. the docstring
> > 5. the key binding
> > 6. the mode or greater package a command is in
> > 7. related commands/variables (by name, location, explicitly listed by
> >    a doc writer, whatever).
> > 8. the customize page
> > 9. home pages of packages (like gnus's home page).
> 
> Sounds good, but how does a user get into the ring in the first place?

Lessee, we currently have:
1. the help menu
2. the items on the splash page

those seem a good start. 

In addition, a general help dialog box might be nice. I imagine
something similar to the searching dialog boxes out there, a text
field and maybe some check boxes for what you want to find or where
you want to search. 

Something extra that would be sweet, but I don't know how feasible it
is, is a context-sensitive way of proposing the most likely help they'd
want. Ideas:
1. a button on the toolbar and/or in the menu to describe the current modes.
2. "what's this?" tooltips or buttons.
3. a minor mode like eldoc that makes the symbols in your elisp files
   clickable, just like we have for info and man pages. Click on a
   symbol to find out more. 

"What's this?" might be particularly useful for the modeline. 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Michael Toomim]

Brady Montz wrote:
> Yes, can't have clippy. I much prefer a passive approach where
> everything is unobtrusively at your fingertips over clippy's obtrusive
> sticking fingers in your eyeball.

I just want to point out that the "software agent" approach (which is the HCI 
research term for what clippy is an instantiation of) is already quite 
ubiquitous in the XEmacs interface.

For instance, if I type M-x some-command-with-a-keybinding, XEmacs will say 
"Hey, you could do that faster by just using C-x M-foo S-bar C-M-S-xfoobar". 
This is just the same as the way clippy tells you shortcuts for doing 
repetitive tasks, and it's really very useful.

Software agents are a great idea... clippy is just a little too obtrusive and 
has way too much personality (nobody like's a microsoft personality).

I say, don't stray away from UI ideas because they are "like clippy".  You can 
have UI features that are remarkably similar to clippy, and remain great features.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Eli Zaretskii]

On Tue, 23 Apr 2002, Michael Toomim wrote:

> For instance, if I type M-x some-command-with-a-keybinding, XEmacs will say 
> "Hey, you could do that faster by just using C-x M-foo S-bar C-M-S-xfoobar". 

This feature already exists, doesn't it?  I think it was even mentioned 
in this thread a couple of days ago.

> Software agents are a great idea... clippy is just a little too obtrusive and 
> has way too much personality (nobody like's a microsoft personality).

I think it's annoying because it pops too frequently and too 
unconditionally, and because it's hard to tell it "get lost!".

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: Brady Montz <bradym@balestra.org>
> > Date: 21 Apr 2002 10:17:13 -0700
> > 
> > I didn't say you didn't use them. Just that I haven't seen many doc
> > strings that take much advantage of them for the "see also" purpose. 
> 
> How about sending bug reports about the missing references?  Or even
> suggesting what related functions/variables should be mentioned in
> specific doc string?

Well, I'm not sure the doc string is the right place for all that
actually. At the very least, I've seen so few doc strings with
a full set of cross-references that if it is a bug report, it would be
a pretty big one.

> > Taking my running example of sort-lines, It's doc tells me about it's
> > config variable sort-fold-case, but I had to do a find-library sort
> > to look at the source to find out about sort-paragraphs, sort-pages,
> > sort-fields, ...
> 
> I think "C-h a sort-" would have told you that faster...

see my other reply to Stephen Turnbull 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Brady Montz <bradym@balestra.org> writes:

> 2. Once I've found a reference to it (an info page, the doc string,
>    the customize gunk), I want better cross referencing.
>
>    We're not too far off here. A "see also" section to the doc strings
>    could be nice.

Customize already has such a fascility (the :link keyword).  It
creates a "See also" section in the customize buffer.  The problem is
to make the programmers make use of it.

And of course, there are the automatic cross references when you
mention a function or a variable in a documentation string.  These are
less flexible, but more useful because they don't rely on programmers
providing them explicitly.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Customize already has such a fascility (the :link keyword).  It
> creates a "See also" section in the customize buffer.  The problem is
> to make the programmers make use of it.

The :link stuff is less than perfect since it doesn't show up in C-h v
etc.  See gnus-treat-* (e.g., `gnus-treat-from-picon' in Oort Gnus)
for how it usually ends up.  IMHO it would be better if customize
groked the "See Info node" magic and created documentation links.
Then the hint and reference would be available from everywhere, and
not restricted to only being available in custom.  Hm.  Another
approach would be if C-h v and friends groked :link.  Maybe that is
better.  Yes, probably.  Existing doc strings that contains duplicated
links in docstring and :link would need to be fixed though.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Hm.  Another approach would be if C-h v and friends groked :link.
> Maybe that is better.  Yes, probably.  Existing doc strings that
> contains duplicated links in docstring and :link would need to be
> fixed though.

Yes, it has been on my list of "small projects I really ought to do"
for some time now.

A more controversial solution would be to 

  (defalias 'describe-variable 'customize-variable)

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > Hm.  Another approach would be if C-h v and friends groked :link.
> > Maybe that is better.  Yes, probably.  Existing doc strings that
> > contains duplicated links in docstring and :link would need to be
> > fixed though.
> 
> Yes, it has been on my list of "small projects I really ought to do"
> for some time now.

I think that's not the best solution for this problem, since there's
already enough information to make such a connection automatically in
the great majority of cases.

> A more controversial solution would be to 
> 
>   (defalias 'describe-variable 'customize-variable)

Yes; that would be very bad.

Customization buffers are filled with all sorts of crap that's
completely unnecessary when you just want to see a quick description of
a variable (which is about 99% of the time for me), which would distract
greatly from the actual documentation (not to mention ballooning the
size of help buffers to something absurd).

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Per Abrahamsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I think that's not the best solution for this problem, since there's
> already enough information to make such a connection automatically in
> the great majority of cases.

There are no conflict in doing both.  Create automatic links when
possible, and additional manual links when not.

>> A more controversial solution would be to 
>> 
>>   (defalias 'describe-variable 'customize-variable)
>
> Yes; that would be very bad.
>
> Customization buffers are filled with all sorts of crap that's
> completely unnecessary when you just want to see a quick description of
> a variable (which is about 99% of the time for me), which would distract
> greatly from the actual documentation (not to mention ballooning the
> size of help buffers to something absurd).

Then make describe-variable a function that called customize-variable
with a 'terse argument.  Or bind a 'customize-terse' dynamic variable.

Most of the new cross-referencing functionality in Emacs 21 was
already part of the doc string widget used by customize.  I think
duplicating the code just lead to inconsistencies and wasted effort.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Simon Josefsson]

On 22 Apr 2002, Miles Bader wrote:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > > Hm.  Another approach would be if C-h v and friends groked :link.
> > > Maybe that is better.  Yes, probably.  Existing doc strings that
> > > contains duplicated links in docstring and :link would need to be
> > > fixed though.
> > 
> > Yes, it has been on my list of "small projects I really ought to do"
> > for some time now.
> 
> I think that's not the best solution for this problem, since there's
> already enough information to make such a connection automatically in
> the great majority of cases.

Are you saying that customize should adopt the "See info node" docstring 
magic instead?

Another reason for that approach instead of the :link one is that it makes
the docstring contain all the documentation, including pointers to other
places.  I think I have changed my mind. Making all code that displays or
parse docstrings somehow support :link as well isn't the best approach.  
It is easier to use the docstring, and have well defined tags such as "See
Info node" convert into buttons for customize.

> > A more controversial solution would be to 
> > 
> >   (defalias 'describe-variable 'customize-variable)
> 
> Yes; that would be very bad.
> 
> Customization buffers are filled with all sorts of crap that's
> completely unnecessary when you just want to see a quick description of
> a variable (which is about 99% of the time for me), which would distract
> greatly from the actual documentation (not to mention ballooning the
> size of help buffers to something absurd).

The customize screen could be cleaned up to solve this.  However, I find
customize-variable slow compared to describe-variable so I agree this
would be a bad solution.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Miles Bader]

Per Abrahamsen <abraham@dina.kvl.dk> writes:
> Most of the new cross-referencing functionality in Emacs 21 was
> already part of the doc string widget used by customize.  I think
> duplicating the code just lead to inconsistencies and wasted effort.

My original suggestion for cleaning up the doc-string hyperlinks
(adding TAB support, etc) last fall was to use the widget library, but
Richard wouldn't allow that, because the widget library is such a huge
wodge of code, most of which is quite unnecessary for the simple
functionality used in help buffers (it's also far to slow to use for
things like apropos, which also need hyperlink support).

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Richard Stallman]

      IMHO it would be better if customize
    groked the "See Info node" magic and created documentation links.

That would be a very good thing.  Would one of you like to implement
that?  It might not be very hard to copy the code from the help
functions to customize.

We would still need someone to go through the various
customizable variables looking for places where it would
be good to add such references to the doc string.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Actually, I believe the trend in HCI research is to avoid or minimize
> the use of dialog boxes.  They really _are_ in the way, also in a GUI.
> This doesn't mean the current (X)Emacs interface is good, it certainly
> isn't intuitive to a new user.

I HATE dialog boxes. Even if they are done OK (you actually CAN do a
search in a program with the dialog box without the box getting in the
way) it still irritates to have this thing flashing in my face. And
don't forget the programming effort for creating and maintaining all
those dialog boxes.

> So I think we really ought to forget about dialog boxes, and instead
> concentrate on making the minibuffer interface more accesible.
> 
> Here is some suggestions:
> 
> 1. Put the minibuffer in the top by default.  It is more visible
>    there, and users of MSIE or Mozilla (and apparently some modern
>    IDE's) will not be surprised to find an input field there.

This seems a good idea. If it's in a clearly seperate "bar" then it
could make the screen less confusing when you have multiple windows
sharing a single minibuffer. 

We also might be able to use this region to clearly show when a
recursive edit is going on. Perhaps a little stack or such.

> 2. Add some strong visual clue (color, animation, whatever) when focus
>    change to the minibuffer.  The toolbar should probably also change
>    to "relevant" buttons for the action, and for those actions that
>    are relevant, a 
> 
> 3. Maybe even have a dialog box (!) pointing to the minibuffer when
>    activating a menu entry that traditionally pop up a dialog.  The
>    box should have an "OK" and a "Don't pop up next time" button.
> 
> 3b Alternatively a "novice" mode, where an arrow point to minibuffer,
>    and a tooltip like message explain what is going on.  Many games
>    teach their UI in that way.  (What a cool way to organize the
>    standard (X)Emacs tutorial!  But I digress).

I think I prefer 3b, preferably after some tooltip sorta
timeout. After 10 seconds of a patiently waiting minibuffer (or if
there's incorrect input), it might be time to give a hint.

I do think that emacs needs a major GUI overhaul if it's to thrive. I
don't know if the minibuffer is the worst offender (IMHO - it's the
ascii art), and I'd rather see a comprehensive rethinking of the GUI
over piecemeal improvements (a dialog here, a menu reorg there). 

Things I would like:

1. actual widgets, with an abstraction layer that allows a single lisp
   spec of them to work on multiple backends - gtk, qt, cocoa,
   vt100. This might restrict them to be fairly simple, but that's not
   necessarily a bad thing. I think speedbar and customize are good
   examples of us straining against the limits of text.

2. one of the things I LOVE about emacs is how easy it is to find
   stuff. "hmmm, I need something to sort a region, what could that
   be." C-h a and there you go. MUCH better than trying to figure out
   something in word, for example. But this assumes a LOT of knowledge
   about emacs. (like "region"). I do think emacs the pack here, but
   it's got SO much stuff to find I believe it needs to make another go at
   advancing the ball.

   I can imagine something where functions not only have a doc string,
   but enough info for a more cleverly interactive browser/searcher
   than M-x apropos to easily find them (we may not need much more for
   that), easily connected to the customize options relating to that
   function, and ideally a mini-tutorial or example code for those
   functions/variables.

   I'd like something where someone can enter a "what do you want to
   do" sorta thing, get a nicely scrollable/searchable table, where
   then can click on each item to customize, read about, or see it in
   action. That would rock.

3. we have a nice set of tools for managing which files/buffers you
   have open and how to switch between them: ibuffer, iswitchb,
   various things like desktop.el, speedbar, buffer-menu, ...

   It might be good to settle on one or a few different ways of using
   all of these and making them more obvious for beginners. Again,
   this plays into an emacs strength. I've used no other editor where
   I could have 200 files open and stay sane. The faster I can find,
   open, and switch to and between files, the happier I
   am. Unfortunately, most beginners I've seen never figure out what
   emacs can do here.

I think all four (including the minibuffer) of these items are
examples of both irritating user-interface deficiencies and great
strenghts emacs has. I love the minibuffer, the ability for simple
little lisp programs to have an interface, having lots of stuff to
find, and a wide variety of file/project management tools. We don't
have to change, damage, dumbify emacs to make it "easier" to use; we
can do a lot to make it easier to use emacs's best features.

My personal interests are (1) and (2). I've been swamped with work for
the last few months, but I'm really wanting to be able to have an
aquafied emacs for my mac. So, I have a lot of personal interest in
working on the "yet another toolkit" issue. And (2) just seems really
neat to me. 

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

At 01:40 PM 4/19/02 +0200, Per Abrahamsen wrote:
>Dialog boxes are so 1980's.

Well so is Windows, but the advantage is that everyone knows how it works - 
you can get up to speed quickly on an application because everything works 
the way you expect. I'm not saying dialog boxes aren't clumsy, inefficient 
etc, etc - but for a bunch of users its what they expect. So it seems to me 
the principle of least surprise applies here.

Not that your points about making the minibuffer more accessible aren't 
good ones. I think the minibuffer is one of emacs' greatest strengths.

amdu

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Richard Stallman]

    2. Add some strong visual clue (color, animation, whatever) when focus
       change to the minibuffer.

Is the colored prompt that appears enough of a visual cue?
If not, what else would you suggest?

    3. Maybe even have a dialog box (!) pointing to the minibuffer when
       activating a menu entry that traditionally pop up a dialog.  The
       box should have an "OK" and a "Don't pop up next time" button.

That would not be hard to implement with the existing facilities.

    1. Put the minibuffer in the top by default.

Would someone like to do this?  Note that there used to be
some things in update_screen that assumed the minibuffer
was at the bottom.

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz]

Andy Piper <andyp@bea.com> writes:

> At 09:27 AM 4/19/02 -0700, Brady Montz wrote:
> >1. actual widgets, with an abstraction layer that allows a single lisp
> >    spec of them to work on multiple backends - gtk, qt, cocoa,
> >    vt100. This might restrict them to be fairly simple, but that's not
> >    necessarily a bad thing. I think speedbar and customize are good
> >    examples of us straining against the limits of text.
> 
> So we actually have this in XEmacs. Its not complete, it has rough edges, but
> its a start. It would be great if we could come up with a standard lisp API
> (common to both XEmacs and Emacs) for doing this sort of stuff. For instance
> this is the XEmacs search dialog:

That's the impression I'd gotten. I haven't yet had the chance to take
a look at it. 

Am I mistaken that the differences between gtk and other native
graphics code is exposed to lisp? That is, the lisp widget library
knows about them?

-- 
 Brady Montz
 bradym@balestra.org

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Richard Stallman]

The feature of using toolkit widgets seems very powerful.  Could you
find out the names of all the people who wrote the code which
implements this?  If they are willing to sign papers, maybe we could
use the code in Emacs.

RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Andy Piper]

> The feature of using toolkit widgets seems very powerful.  Could you
> find out the names of all the people who wrote the code which
> implements this?  If they are willing to sign papers, maybe we could
> use the code in Emacs.

I think the copyright for this particular feature is almost exclusively
owned by me. However, the code all relies on support that Ben wrote - so you
would need to get papers from both Ben and me.

Circumstances have prevented me doing this in tne past, it may be things are
different now. We'll see.

andy

Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[William M. Perry]

Richard Stallman <rms@gnu.org> writes:

> The feature of using toolkit widgets seems very powerful.  Could you find
> out the names of all the people who wrote the code which implements this?
> If they are willing to sign papers, maybe we could use the code in Emacs.

For the actual lisp bindings for GTK were done by me, and papers should not
be a problem.  It would be fairly simple to write similar support for X.

-bp
-- 
Ceterum censeo vi esse delendam