From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: auto-update of Info dir file? Date: Tue, 16 May 2006 12:33:39 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1147808070 2630 80.91.229.2 (16 May 2006 19:34:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 May 2006 19:34:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 16 21:34:28 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fg5JA-0003U7-AL for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 21:34:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fg5J9-0001j8-OO for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 15:34:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fg5Ik-0001d1-5k for emacs-devel@gnu.org; Tue, 16 May 2006 15:33:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fg5Ij-0001cd-AS for emacs-devel@gnu.org; Tue, 16 May 2006 15:33:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fg5Ij-0001cX-2y for emacs-devel@gnu.org; Tue, 16 May 2006 15:33:49 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1Fg5LQ-0003hN-FZ for emacs-devel@gnu.org; Tue, 16 May 2006 15:36:36 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k4GJXjKw011974 for ; Tue, 16 May 2006 13:33:46 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-26.vpn.oracle.com [141.144.73.26]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k4GJXihS028342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 May 2006 13:33:45 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54604 Archived-At: > The end user might not know that s?he wants a particular manual. ??? Really? Really. Tell me, when you want to read some manual, how do you get to it if not by "C-h i d m MUMBLE " (or something equivalent)? In other words, you _always_ name the manual that you want to read. I don't want to belabor this, but my answer is no, I do not use `C-h i d m' or `C-h i m' very often, and I suspect that some other users might not either. I use `C-h i' and then click the manual's link in the menu. Of course that's equivalent, but some users will use Info in an exploratory fashion, to discover more of what is available. I have probably never looked at at least 2/3 of the manuals that are in my `dir', but I might someday. If I do, the first thing I will do is browse the list to see what I might be interested in. That requires that the list be complete (populated). Preferably, the list would be complete not only with file names but also with brief descriptions (perhaps constructed automatically). Yes, the `m' command, if fixed as you proposed (a la standalone `info'), would let people explore via completion, so that's a good start. But why not populate the _visible_ menu too, while we're at it? Why populate only the invisible "menu" provided by `m' completion? When you go to the library or bookstore, do you always go looking for a particular book? Don't you sometimes browse the shelves to see what might be interesting? > If the manual doesn't appear in the Info list (catch-22), > then the user might not even be aware that the manual exists. How long is your top-level menu? On Emacs 20 on Windows: 28 manuals. On Emacs 22 on Windows: 41 manuals. Mine is _very_ long, and the same will happen to anyone who has glibc docs installed, because they add an entry for each and every function in the library. But even if there's no glibc entries in DIR, a garden variety top-level menu is quote long: for example, the one on gnu.org machines has 623 lines. Well, yours is certainly longer than mine, Eli! ;-) So, to avoid wasting precious time, I _never_ scan the menu to find whether a topic I'm looking for is there, I type "m SOMETHING " and watch the result: if there's no such topic, Info will bitch at me. Different users have different use patterns. Different users have different menus. Different users have different sizes. I've been known to browse a bookstore or library no matter how big it is (Library of Congress?). Call me inefficient. You really raise a different issue, I think, which is how to help users manage a long `dir' menu? It might be useful to brainstorm ideas in that area. Perhaps structuring the menu more? Perhaps providing a special search functionality for it? I agree that the completion available via the `m' command is useful in this regard (especially with Icicles completion!), but perhaps there is room for additional help. Library and bookstore card catalogs and computerized searches for books make it possible to manage even _humongous_ inventories of books as an end user. And they are not limited to, say, the equivalent of `C-h i d m '. Nevertheless, there is still a need (rather, a preference) on the part of some users in some libraries on some rainy days to browse some of the stacks and peruse some of the books. Some people never learn (`C-h i d m'). > The idea was to have invocation of Emacs command `info' > populate Info with all available manuals, without the > end user needing to know anything about what they are. And I thought the idea was to allow the user to reach a manual even though it was not installed by `install-info'. That's a consequence of the idea I proposed, which was to populate the menu automatically. And yes, that is desirable. But it's not the full goal. Populating the top-level menu with all manuals is a means to an end; I suggested a different means to the very same end, I think. The end is not the same if the end is reduced to a limited way (invisible menu) to "reach a manual". I would like to see the visible menu populated too, so users, especially novice users, can browse what they see there - that's part of the end pursued by my proposal, it's not just a means to it. > Also, how will Emacs tell what "the user wants" in this > context? Even if the end user does know that s?he wants > a particular manual (and that it should > be available), how is that communicated to Emacs in your scenario? It's the string the user types at `m's prompt in the top-level menu. Too limiting; see above. > I think this should be push rather than pull. That is, populating > Info should not be demand-driven by the user; it should be done > automatically, based on all available Info files. It can be > demand-driven in terms of _when_ it happens (dynamically, when > the user invokes Emacs command `info' for the first time in a > session), but not in terms of _which_ manuals end up > populating the `dir' file. I didn't say anything about populating the menu. My suggestion involves no modifications to the menu, Info will just find the manual even if it isn't in the menu. _I_ did say something about populating the menu, right from the start. My proposal is different from yours, not only in the means, but also in the end pursued. Making sure that completion for `m' has the complete list of books is necessary, but it is not sufficient. The visible menu should also be complete. To see how the stand-alone Info reader handles this, type at the shell's prompt "info info-stnd". There should be no menu entry that begins with the string "info-stnd" in your DIR file, but the stand-alone reader will find the right manual anyway. Yes, I have no problem with that, as far as it goes. I would also like to see the visible menu show what's available, so users don't need a crystal ball before they can know to type "info info-stnd". Even if seen in a completion list, "info-stnd" is hardly parlant. The same thing goes for the visible menu: It would be good to find some way to add a (constructed) description for the books added automatically to the (visible) menu. Ideally (another, future discussion, perhaps), users should be able to type keywords or a regexp and see a summary of the hits among all manuals - to see which manuals might be available and most appropriate for info on a particular subject. To me, this is about helping users to know which manuals are available. It is not just about "reaching a manual" that you know you want to read.