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

[Brady Montz <bradym@balestra.org>]

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