[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-dat
From: |
Brady Montz |
Subject: |
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) |
Date: |
20 Apr 2002 19:06:32 -0700 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) |
Richard Stallman <address@hidden> 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
address@hidden
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), (continued)
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Robert J. Chassell, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Alfred M. Szmidt, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Terje Bless, 2002/04/20
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Serge Wroclawski, 2002/04/20
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/20
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Matt Tucker, 2002/04/20
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Richard Stallman, 2002/04/20
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date),
Brady Montz <=
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Eli Zaretskii, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Stephen J. Turnbull, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Eli Zaretskii, 2002/04/21
- Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/22
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Stephen J. Turnbull, 2002/04/21
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/22
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Eli Zaretskii, 2002/04/22
Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date), Brady Montz, 2002/04/22