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

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)

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

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

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

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

[Samuel Mikes]

Brady> 3. I want demos or examples. For some things, just having a
Brady> little sandbox buffer seeded with apropriate text would be

Brady> Obviously, demos/examples are very specific, and would
Brady> probably be written by the code's authors or other interested
Brady> parties. Having a nice support mechanism for this to make it
Brady> as simple as possible, along with the consensus to move

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

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

  I hacked up something in this line.  You can see the c-mode
tutorial that I'm working on as an example:

http://www.cubane.com/c-mode-tutorial.tar.gz
ftp://ftp.cubane.com/pub/c-mode-tutorial.tar.gz

  The tutorial code embeds pushbutton widgets in the tutorial
buffer.  The syntax is very simple but should be sufficient for
simple tutorials; I wrote some helper functions to pop up example
buffers.  For example, you could make a pushbutton run
(customize-variable 'c-default-style).

  I have tested it on XEmacs 21.4 on msw and tty.  I don't currently
have a modern GNU Emacs, but I believe GNU Emacs >19 comes with
widget and wid-edit, so it should work.

  My original motivation for writing this particular tutorial comes
from helping with an undergrad intro programming course some years
ago.  The students would sit down at a Windows box and telnet to the
unix machine.  They'd start emacs to write some code, then kill
emacs, compile the code, memorize the line number of the first syntax
error, restart emacs, fix the syntax error, kill emacs, ...

  If tutorials like this would be useful, (some of) the next
questions are:

 o What would make the tutorial easier to use?
 o What needs to happen for them to be distributed with Emacs/XEmacs?
 o What is a good way to guide users towards the tutorials?

I don't think a talking paperclip would be appropriate, but maybe the
first time you enter c-mode, a prompt such as:

"This is the first time you've used c-mode.  Would you like to see a
short tutorial about writing C in Emacs? (yes/no/Never offer me a
tutorial again) "

Please send comments/criticism on the tutorial to smikes@cubane.com.
-- 
Sam Mikes
smikes@cubane.com

Re: Tutorials and Demos

[Robin S. Socha]

* Samuel Mikes <smikes@cubane.com> writes:

> I hacked up something in this line.  You can see the c-mode tutorial
> that I'm working on as an example:
> 
> http://www.cubane.com/c-mode-tutorial.tar.gz
> ftp://ftp.cubane.com/pub/c-mode-tutorial.tar.gz

One thing I've always not quite liked about (X)Emacs is the lack of a central
dump for user-contributed information. There are the two main websites, and
on top of that a *lot* of more or less small sites that all carry more or
less vital information. But they all look different, the Emacs webring hasn't
really helped, and well... 

With rather amateurish means, we've tried to put together something that
goes beyond that: <http://my.gnus.org/>

MGO tries to encourage users to contribute to (in this case) Gnus in
whatever way they can. We've put up a means of easily submitting and
publishing Documentation (see <http://my.gnus.org/HowTos>), Code
<http://my.gnus.org/Lisp>, Wikis
<http://my.gnus.org/Members/robin/Wiki/> and weblogs
<http://my.gnus.org/Members/robin/blark/>. Also, there are screenshots,
announcement facilities etc. You can see the machinery behind it in full
action at <http://zope.org/>.

Ah, and we give away email accounts for Members :-)

Anyway, I think it'd be neat if someone picked up the idea and made
something like this (on a larger scale, this is just a hobby project
driven by 5 people) for both Emacsen. E.g. while I find this thread
highly interesting, it will suck to read it in a webarchive for later
generations. The Zope devel proposals are up on the web and can be
commented on - since ZWikis can be edited with (X)Emacs, it's almost the
same as writing mail :-)
<http://www.zope.org/Wikis/DevSite/Proposals/FrontPage>

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

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