From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Brady Montz Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: 20 Apr 2002 19:06:32 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <4.3.2.7.2.20020417123512.0398e4c8@san-francisco.beasys.com> <200204201727.g3KHRTg01417@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019354966 23996 127.0.0.1 (21 Apr 2002 02:09:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 02:09:26 +0000 (UTC) Cc: xemacs-design@xemacs.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16z6n7-0006Ev-00 for ; Sun, 21 Apr 2002 04:09:25 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16z6n7-0006xN-00 for ; Sun, 21 Apr 2002 04:09:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z6ms-0001cB-00; Sat, 20 Apr 2002 22:09:10 -0400 Original-Received: from c64-255-216-95.sea1.cablespeed.com ([64.255.216.95] helo=sandman.balestra.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z6kM-0001SB-00; Sat, 20 Apr 2002 22:06:34 -0400 Original-Received: (from bradym@localhost) by sandman.balestra.org (8.10.2/8.10.2) id g3L26Wj07880; Sat, 20 Apr 2002 19:06:32 -0700 (PDT) X-Authentication-Warning: sandman.balestra.org: bradym set sender to bradym@balestra.org using -f Original-To: rms@gnu.org In-Reply-To: <200204201727.g3KHRTg01417@aztec.santafe.edu> Original-Lines: 106 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2897 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2897 Richard Stallman 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