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: 23 Apr 2002 09:21:59 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp> <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019579081 24953 127.0.0.1 (23 Apr 2002 16:24:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2002 16:24:41 +0000 (UTC) Cc: Eli Zaretskii , 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 17035t-0006UM-00 for ; Tue, 23 Apr 2002 18:24:41 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 170379-0008H5-00 for ; Tue, 23 Apr 2002 18:25:59 +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 17035U-000312-00; Tue, 23 Apr 2002 12:24:16 -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 17033V-0002tC-00 for ; Tue, 23 Apr 2002 12:22:13 -0400 Original-Received: (from bradym@localhost) by sandman.balestra.org (8.10.2/8.10.2) id g3NGM0T06550; Tue, 23 Apr 2002 09:22:00 -0700 (PDT) X-Authentication-Warning: sandman.balestra.org: bradym set sender to bradym@balestra.org using -f Original-To: "Stephen J. Turnbull" In-Reply-To: <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> Original-Lines: 110 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:3115 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3115 "Stephen J. Turnbull" writes: > >>>>> "Brady" == Brady Montz 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