* The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] <4.3.2.7.2.20020417123512.0398e4c8@san-francisco.beasys.com> @ 2002-04-19 11:40 ` Per Abrahamsen [not found] ` <rjk7r3zzk4.fsf@zuse.dina.kvl.dk> ` (4 subsequent siblings) 5 siblings, 0 replies; 46+ messages in thread From: Per Abrahamsen @ 2002-04-19 11:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <rjk7r3zzk4.fsf@zuse.dina.kvl.dk>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <rjk7r3zzk4.fsf@zuse.dina.kvl.dk> @ 2002-04-19 16:27 ` Brady Montz 2002-04-19 16:55 ` Andy Piper 2002-04-20 17:27 ` Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-19 16:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <rjk7r3zzk4.fsf@zuse.dina.kvl.dk> 2002-04-19 16:27 ` Brady Montz @ 2002-04-19 16:55 ` Andy Piper 2002-04-20 17:27 ` Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Andy Piper @ 2002-04-19 16:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <rjk7r3zzk4.fsf@zuse.dina.kvl.dk> 2002-04-19 16:27 ` Brady Montz 2002-04-19 16:55 ` Andy Piper @ 2002-04-20 17:27 ` Richard Stallman 2 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2002-04-20 17:27 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2g01rbjhi.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2g01rbjhi.fsf@sandman.balestra.org> @ 2002-04-19 20:28 ` Andy Piper 0 siblings, 0 replies; 46+ messages in thread From: Andy Piper @ 2002-04-19 20:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2d6wvodpt.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2d6wvodpt.fsf@sandman.balestra.org> @ 2002-04-19 17:00 ` Andy Piper 2002-04-20 11:03 ` Terje Bless ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Andy Piper @ 2002-04-19 17:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2d6wvodpt.fsf@sandman.balestra.org> 2002-04-19 17:00 ` Andy Piper @ 2002-04-20 11:03 ` Terje Bless 2002-04-20 17:27 ` Richard Stallman [not found] ` <200204201727.g3KHRTg01417@aztec.santafe.edu> 3 siblings, 0 replies; 46+ messages in thread From: Terje Bless @ 2002-04-20 11:03 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2d6wvodpt.fsf@sandman.balestra.org> 2002-04-19 17:00 ` Andy Piper 2002-04-20 11:03 ` Terje Bless @ 2002-04-20 17:27 ` Richard Stallman [not found] ` <200204201727.g3KHRTg01417@aztec.santafe.edu> 3 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2002-04-20 17:27 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <200204201727.g3KHRTg01417@aztec.santafe.edu>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <200204201727.g3KHRTg01417@aztec.santafe.edu> @ 2002-04-21 2:06 ` Brady Montz [not found] ` <m2wuv1yfdj.fsf@sandman.balestra.org> 1 sibling, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-21 2:06 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2wuv1yfdj.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2wuv1yfdj.fsf@sandman.balestra.org> @ 2002-04-21 6:48 ` Eli Zaretskii 2002-04-21 7:35 ` Brady Montz 2002-04-21 9:01 ` Per Abrahamsen ` (2 subsequent siblings) 3 siblings, 1 reply; 46+ messages in thread From: Eli Zaretskii @ 2002-04-21 6:48 UTC (permalink / raw) Cc: rms, xemacs-design, emacs-devel 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... ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-21 6:48 ` Eli Zaretskii @ 2002-04-21 7:35 ` Brady Montz 2002-04-21 15:31 ` Stephen J. Turnbull [not found] ` <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> 0 siblings, 2 replies; 46+ messages in thread From: Brady Montz @ 2002-04-21 7:35 UTC (permalink / raw) Cc: rms, xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-21 7:35 ` Brady Montz @ 2002-04-21 15:31 ` Stephen J. Turnbull [not found] ` <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> 1 sibling, 0 replies; 46+ messages in thread From: Stephen J. Turnbull @ 2002-04-21 15:31 UTC (permalink / raw) Cc: Eli Zaretskii, rms, xemacs-design, emacs-devel >>>>> "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> @ 2002-04-21 17:17 ` Brady Montz 2002-04-21 18:49 ` Eli Zaretskii [not found] ` <m2d6wtx97q.fsf@sandman.balestra.org> 2 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-21 17:17 UTC (permalink / raw) Cc: Eli Zaretskii, rms, xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-21 17:17 ` Brady Montz @ 2002-04-21 18:49 ` Eli Zaretskii [not found] ` <m2d6wtx97q.fsf@sandman.balestra.org> 2 siblings, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-21 18:49 UTC (permalink / raw) Cc: bradym, rms, xemacs-design, emacs-devel > 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2d6wtx97q.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2d6wtx97q.fsf@sandman.balestra.org> @ 2002-04-21 19:09 ` Eli Zaretskii 2002-04-22 2:58 ` Stephen J. Turnbull ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-21 19:09 UTC (permalink / raw) Cc: stephen, rms, xemacs-design, emacs-devel > 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... ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2d6wtx97q.fsf@sandman.balestra.org> 2002-04-21 19:09 ` Eli Zaretskii @ 2002-04-22 2:58 ` Stephen J. Turnbull [not found] ` <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp> [not found] ` <2950-Sun21Apr2002220958+0300-eliz@is.elta.co.il> 3 siblings, 0 replies; 46+ messages in thread From: Stephen J. Turnbull @ 2002-04-22 2:58 UTC (permalink / raw) Cc: xemacs-design, emacs-devel >>>>> "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp> @ 2002-04-22 16:54 ` Brady Montz [not found] ` <m2elh7wu6m.fsf@sandman.balestra.org> 1 sibling, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-22 16:54 UTC (permalink / raw) Cc: xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2elh7wu6m.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2elh7wu6m.fsf@sandman.balestra.org> @ 2002-04-22 19:40 ` Eli Zaretskii [not found] ` <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> 1 sibling, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-22 19:40 UTC (permalink / raw) Cc: xemacs-design, emacs-devel > 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). ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> @ 2002-04-22 20:46 ` Brady Montz 2002-04-23 4:03 ` Stephen J. Turnbull ` (3 more replies) 0 siblings, 4 replies; 46+ messages in thread From: Brady Montz @ 2002-04-22 20:46 UTC (permalink / raw) Cc: xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-22 20:46 ` Brady Montz @ 2002-04-23 4:03 ` Stephen J. Turnbull 2002-04-23 6:31 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: Stephen J. Turnbull @ 2002-04-23 4:03 UTC (permalink / raw) Cc: Eli Zaretskii, xemacs-design, emacs-devel >>>>> "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-22 20:46 ` Brady Montz 2002-04-23 4:03 ` Stephen J. Turnbull @ 2002-04-23 6:31 ` Eli Zaretskii [not found] ` <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-23 23:00 ` Michael Toomim 3 siblings, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-23 6:31 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> @ 2002-04-23 6:41 ` Eli Zaretskii 2002-04-23 16:21 ` Brady Montz [not found] ` <m2r8l6v108.fsf@sandman.balestra.org> 2 siblings, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-23 6:41 UTC (permalink / raw) Cc: Brady Montz, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-23 6:41 ` Eli Zaretskii @ 2002-04-23 16:21 ` Brady Montz [not found] ` <m2r8l6v108.fsf@sandman.balestra.org> 2 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-23 16:21 UTC (permalink / raw) Cc: Eli Zaretskii, xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <m2r8l6v108.fsf@sandman.balestra.org>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2r8l6v108.fsf@sandman.balestra.org> @ 2002-04-23 17:09 ` Stephen J. Turnbull [not found] ` <878z7euysa.fsf@tleepslib.sk.tsukuba.ac.jp> 1 sibling, 0 replies; 46+ messages in thread From: Stephen J. Turnbull @ 2002-04-23 17:09 UTC (permalink / raw) Cc: xemacs-design, emacs-devel >>>>> "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <878z7euysa.fsf@tleepslib.sk.tsukuba.ac.jp>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <878z7euysa.fsf@tleepslib.sk.tsukuba.ac.jp> @ 2002-04-23 18:20 ` Brady Montz 2002-04-23 19:21 ` Eli Zaretskii [not found] ` <7263-Tue23Apr2002222135+0300-eliz@is.elta.co.il> 0 siblings, 2 replies; 46+ messages in thread From: Brady Montz @ 2002-04-23 18:20 UTC (permalink / raw) Cc: xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-23 18:20 ` Brady Montz @ 2002-04-23 19:21 ` Eli Zaretskii [not found] ` <7263-Tue23Apr2002222135+0300-eliz@is.elta.co.il> 1 sibling, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-23 19:21 UTC (permalink / raw) Cc: xemacs-design, emacs-devel > 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? ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <7263-Tue23Apr2002222135+0300-eliz@is.elta.co.il>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <7263-Tue23Apr2002222135+0300-eliz@is.elta.co.il> @ 2002-04-23 19:56 ` Brady Montz 0 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-23 19:56 UTC (permalink / raw) Cc: xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-22 20:46 ` Brady Montz ` (2 preceding siblings ...) [not found] ` <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> @ 2002-04-23 23:00 ` Michael Toomim 2002-04-24 6:09 ` Eli Zaretskii 3 siblings, 1 reply; 46+ messages in thread From: Michael Toomim @ 2002-04-23 23:00 UTC (permalink / raw) Cc: Eli Zaretskii, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-23 23:00 ` Michael Toomim @ 2002-04-24 6:09 ` Eli Zaretskii 0 siblings, 0 replies; 46+ messages in thread From: Eli Zaretskii @ 2002-04-24 6:09 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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!". ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <2950-Sun21Apr2002220958+0300-eliz@is.elta.co.il>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <2950-Sun21Apr2002220958+0300-eliz@is.elta.co.il> @ 2002-04-22 16:56 ` Brady Montz 0 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-22 16:56 UTC (permalink / raw) Cc: stephen, rms, xemacs-design, emacs-devel "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2wuv1yfdj.fsf@sandman.balestra.org> 2002-04-21 6:48 ` Eli Zaretskii @ 2002-04-21 9:01 ` Per Abrahamsen 2002-04-21 20:21 ` Simon Josefsson [not found] ` <ilusn5o950a.fsf@extundo.com> 2002-04-23 20:10 ` Tutorials and Demos (Re: " Samuel Mikes [not found] ` <15557.49069.908484.860930@marvin.cubane.com> 3 siblings, 2 replies; 46+ messages in thread From: Per Abrahamsen @ 2002-04-21 9:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-21 9:01 ` Per Abrahamsen @ 2002-04-21 20:21 ` Simon Josefsson [not found] ` <ilusn5o950a.fsf@extundo.com> 1 sibling, 0 replies; 46+ messages in thread From: Simon Josefsson @ 2002-04-21 20:21 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <ilusn5o950a.fsf@extundo.com>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <ilusn5o950a.fsf@extundo.com> @ 2002-04-22 8:50 ` Per Abrahamsen 2002-04-22 9:00 ` Miles Bader [not found] ` <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp> 2002-04-22 22:36 ` Richard Stallman 1 sibling, 2 replies; 46+ messages in thread From: Per Abrahamsen @ 2002-04-22 8:50 UTC (permalink / raw) Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) 2002-04-22 8:50 ` Per Abrahamsen @ 2002-04-22 9:00 ` Miles Bader [not found] ` <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp> 1 sibling, 0 replies; 46+ messages in thread From: Miles Bader @ 2002-04-22 9:00 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp> @ 2002-04-22 10:44 ` Per Abrahamsen 2002-04-22 11:12 ` Simon Josefsson [not found] ` <rjk7r0ovw9.fsf@zuse.dina.kvl.dk> 2 siblings, 0 replies; 46+ messages in thread From: Per Abrahamsen @ 2002-04-22 10:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp> 2002-04-22 10:44 ` Per Abrahamsen @ 2002-04-22 11:12 ` Simon Josefsson [not found] ` <rjk7r0ovw9.fsf@zuse.dina.kvl.dk> 2 siblings, 0 replies; 46+ messages in thread From: Simon Josefsson @ 2002-04-22 11:12 UTC (permalink / raw) Cc: Per Abrahamsen, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <rjk7r0ovw9.fsf@zuse.dina.kvl.dk>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <rjk7r0ovw9.fsf@zuse.dina.kvl.dk> @ 2002-04-22 12:36 ` Miles Bader 0 siblings, 0 replies; 46+ messages in thread From: Miles Bader @ 2002-04-22 12:36 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <ilusn5o950a.fsf@extundo.com> 2002-04-22 8:50 ` Per Abrahamsen @ 2002-04-22 22:36 ` Richard Stallman 1 sibling, 0 replies; 46+ messages in thread From: Richard Stallman @ 2002-04-22 22:36 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Tutorials and Demos (Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <m2wuv1yfdj.fsf@sandman.balestra.org> 2002-04-21 6:48 ` Eli Zaretskii 2002-04-21 9:01 ` Per Abrahamsen @ 2002-04-23 20:10 ` Samuel Mikes [not found] ` <15557.49069.908484.860930@marvin.cubane.com> 3 siblings, 0 replies; 46+ messages in thread From: Samuel Mikes @ 2002-04-23 20:10 UTC (permalink / raw) Cc: xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <15557.49069.908484.860930@marvin.cubane.com>]
* Re: Tutorials and Demos [not found] ` <15557.49069.908484.860930@marvin.cubane.com> @ 2002-04-24 4:37 ` Robin S. Socha 0 siblings, 0 replies; 46+ messages in thread From: Robin S. Socha @ 2002-04-24 4:37 UTC (permalink / raw) * 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> ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <4.3.2.7.2.20020419095654.00bee3c0@san-francisco.beasys.com>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <4.3.2.7.2.20020419095654.00bee3c0@san-francisco.beasys.com> @ 2002-04-19 19:01 ` Brady Montz 2002-04-20 17:28 ` Richard Stallman [not found] ` <200204201728.g3KHSDW01513@aztec.santafe.edu> 2 siblings, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-19 19:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <4.3.2.7.2.20020419095654.00bee3c0@san-francisco.beasys.com> 2002-04-19 19:01 ` The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Brady Montz @ 2002-04-20 17:28 ` Richard Stallman [not found] ` <200204201728.g3KHSDW01513@aztec.santafe.edu> 2 siblings, 0 replies; 46+ messages in thread From: Richard Stallman @ 2002-04-20 17:28 UTC (permalink / raw) Cc: bradym, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <200204201728.g3KHSDW01513@aztec.santafe.edu>]
* RE: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <200204201728.g3KHSDW01513@aztec.santafe.edu> @ 2002-04-20 21:45 ` Andy Piper 2002-04-21 15:54 ` William M. Perry 1 sibling, 0 replies; 46+ messages in thread From: Andy Piper @ 2002-04-20 21:45 UTC (permalink / raw) Cc: bradym, xemacs-design, emacs-devel > 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <200204201728.g3KHSDW01513@aztec.santafe.edu> 2002-04-20 21:45 ` Andy Piper @ 2002-04-21 15:54 ` William M. Perry 1 sibling, 0 replies; 46+ messages in thread From: William M. Perry @ 2002-04-21 15:54 UTC (permalink / raw) Cc: andyp, bradym, xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <4.3.2.7.2.20020419132421.00bfa9d0@san-francisco.beasys.com>]
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <4.3.2.7.2.20020419132421.00bfa9d0@san-francisco.beasys.com> @ 2002-04-19 20:39 ` Brady Montz 2002-04-20 23:53 ` William M. Perry 1 sibling, 0 replies; 46+ messages in thread From: Brady Montz @ 2002-04-19 20:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) [not found] ` <4.3.2.7.2.20020419132421.00bfa9d0@san-francisco.beasys.com> 2002-04-19 20:39 ` Brady Montz @ 2002-04-20 23:53 ` William M. Perry 1 sibling, 0 replies; 46+ messages in thread From: William M. Perry @ 2002-04-20 23:53 UTC (permalink / raw) Cc: Brady Montz, xemacs-design, emacs-devel 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2002-04-24 6:09 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4.3.2.7.2.20020417123512.0398e4c8@san-francisco.beasys.com> 2002-04-19 11:40 ` The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Per Abrahamsen [not found] ` <rjk7r3zzk4.fsf@zuse.dina.kvl.dk> 2002-04-19 16:27 ` Brady Montz 2002-04-19 16:55 ` Andy Piper 2002-04-20 17:27 ` Richard Stallman [not found] ` <m2g01rbjhi.fsf@sandman.balestra.org> 2002-04-19 20:28 ` Andy Piper [not found] ` <m2d6wvodpt.fsf@sandman.balestra.org> 2002-04-19 17:00 ` Andy Piper 2002-04-20 11:03 ` Terje Bless 2002-04-20 17:27 ` Richard Stallman [not found] ` <200204201727.g3KHRTg01417@aztec.santafe.edu> 2002-04-21 2:06 ` Brady Montz [not found] ` <m2wuv1yfdj.fsf@sandman.balestra.org> 2002-04-21 6:48 ` Eli Zaretskii 2002-04-21 7:35 ` Brady Montz 2002-04-21 15:31 ` Stephen J. Turnbull [not found] ` <87vgal3w79.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-21 17:17 ` Brady Montz 2002-04-21 18:49 ` Eli Zaretskii [not found] ` <m2d6wtx97q.fsf@sandman.balestra.org> 2002-04-21 19:09 ` Eli Zaretskii 2002-04-22 2:58 ` Stephen J. Turnbull [not found] ` <87vgak30cw.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-22 16:54 ` Brady Montz [not found] ` <m2elh7wu6m.fsf@sandman.balestra.org> 2002-04-22 19:40 ` Eli Zaretskii [not found] ` <7263-Mon22Apr2002224014+0300-eliz@is.elta.co.il> 2002-04-22 20:46 ` Brady Montz 2002-04-23 4:03 ` Stephen J. Turnbull 2002-04-23 6:31 ` Eli Zaretskii [not found] ` <87bscbysbm.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-23 6:41 ` Eli Zaretskii 2002-04-23 16:21 ` Brady Montz [not found] ` <m2r8l6v108.fsf@sandman.balestra.org> 2002-04-23 17:09 ` Stephen J. Turnbull [not found] ` <878z7euysa.fsf@tleepslib.sk.tsukuba.ac.jp> 2002-04-23 18:20 ` Brady Montz 2002-04-23 19:21 ` Eli Zaretskii [not found] ` <7263-Tue23Apr2002222135+0300-eliz@is.elta.co.il> 2002-04-23 19:56 ` Brady Montz 2002-04-23 23:00 ` Michael Toomim 2002-04-24 6:09 ` Eli Zaretskii [not found] ` <2950-Sun21Apr2002220958+0300-eliz@is.elta.co.il> 2002-04-22 16:56 ` Brady Montz 2002-04-21 9:01 ` Per Abrahamsen 2002-04-21 20:21 ` Simon Josefsson [not found] ` <ilusn5o950a.fsf@extundo.com> 2002-04-22 8:50 ` Per Abrahamsen 2002-04-22 9:00 ` Miles Bader [not found] ` <buoy9fg85ve.fsf@mcspd15.ucom.lsi.nec.co.jp> 2002-04-22 10:44 ` Per Abrahamsen 2002-04-22 11:12 ` Simon Josefsson [not found] ` <rjk7r0ovw9.fsf@zuse.dina.kvl.dk> 2002-04-22 12:36 ` Miles Bader 2002-04-22 22:36 ` Richard Stallman 2002-04-23 20:10 ` Tutorials and Demos (Re: " Samuel Mikes [not found] ` <15557.49069.908484.860930@marvin.cubane.com> 2002-04-24 4:37 ` Tutorials and Demos Robin S. Socha [not found] ` <4.3.2.7.2.20020419095654.00bee3c0@san-francisco.beasys.com> 2002-04-19 19:01 ` The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Brady Montz 2002-04-20 17:28 ` Richard Stallman [not found] ` <200204201728.g3KHSDW01513@aztec.santafe.edu> 2002-04-20 21:45 ` Andy Piper 2002-04-21 15:54 ` William M. Perry [not found] ` <4.3.2.7.2.20020419132421.00bfa9d0@san-francisco.beasys.com> 2002-04-19 20:39 ` Brady Montz 2002-04-20 23:53 ` William M. Perry
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).