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: Have you all gone crazy? Was: On being web-friendly and why info must die Date: Mon, 22 Dec 2014 22:21:44 -0800 (PST) Message-ID: References: <87388bnzha.fsf@newcastle.ac.uk> <87k31mdbhe.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx0qiv45.fsf@fencepost.gnu.org> <87h9wqd3i5.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvc8kdsp.fsf@gnu.org> <6e11cd85-09a0-4b7a-baa2-0c810bdebbce@default> <871tnsg0w7.fsf@fencepost.gnu.org> <834msoqrsg.fsf@gnu.org> <5498C82D.5080605@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1419315770 12922 80.91.229.3 (23 Dec 2014 06:22:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Dec 2014 06:22:50 +0000 (UTC) Cc: Eli Zaretskii , Tom , Emacs-Devel devel To: Paul Eggert , Yuri Khan , Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 23 07:22:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y3Irh-0003Ml-P0 for ged-emacs-devel@m.gmane.org; Tue, 23 Dec 2014 07:22:42 +0100 Original-Received: from localhost ([::1]:43250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3Irg-0007Bk-Oo for ged-emacs-devel@m.gmane.org; Tue, 23 Dec 2014 01:22:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3IrN-0007Aj-FZ for emacs-devel@gnu.org; Tue, 23 Dec 2014 01:22:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3IrE-00005M-O1 for emacs-devel@gnu.org; Tue, 23 Dec 2014 01:22:21 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:30002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3Ir5-0008VB-Ii; Tue, 23 Dec 2014 01:22:03 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBN6LkjE018009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 06:21:47 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sBN6Ljhe010772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Dec 2014 06:21:46 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBN6LjD4001682; Tue, 23 Dec 2014 06:21:45 GMT In-Reply-To: <5498C82D.5080605@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180539 Archived-At: > how composite glyphs work in Emacs... I went to the Emacs manual > in info mode and typed 'i composite RET'; the response was "No > `composite' in index" To begin with, I would expect that the Emacs manual would be a bad choice for information about composite glyphs. (Char composition is covered briefly in the Emacs manual, and if you type `compos TAB' then you see candidate `compose character'. But that's not the same thing.) > Since I'm supposedly expert I switched to the for-experts-only > Elisp manual=20 It is not at all for-experts-only. It is simply the Lisp manual for Emacs. > and typed 'i composite RET', and got sent to an irrelevant page > about composite types. FWIW, had you typed `compos TAB', that would have been expanded to `composit', and you would have seen candidates `composition (text property)' and `composition property, and point display', together with the irrelevant entry you followed, `composite types (customization)'. > In short, the info-mode indexes were utterly a failure for > this example. Eggert-mode + info-mode was utterly a failure for this example. ;-) > Which isn't surprising, since none of the Emacs manuals talk about > composite glyphs anywhere. (I verified this by using other tools, > as this was faster than using info mode would have been.) Hm. They might not cover the information you want, but it's not true that they do not talk about composite glyphs anywhere. `composition' This text property is used to display a sequence of characters as a single glyph composed from components. But the value of the property itself is completely internal to Emacs and should not be manipulated directly by, for instance, `put-text-property'. But yes, that is not very much info about composite glyphs. If the info you are looking for is *not in the manuals*, then it is certainly not a failure of their indexing that consulting the indexes didn't help you find that info. That's a no-brainer. > In contrast, Google searches were reasonably helpful. No, not wrt the Emacs manual; not per your example. No one has claimed that the Emacs manuals replace Internet-wide searches for information about Emacs. Or that they should or could do that. Red herring. It's not about one or the other, manuals vs Internet. There will always be more information about Emacs on the Internet than is contained in the Emacs manuals - the manuals are on the Internet. > The search '"composite glyph"' quickly got me up to speed on > the general topic, and '"composite glyph" Emacs' gave me helpful > bug reports that let me intuit relevant issues reasonably well. No one denies that Internet searching is powerful and helpful. But it didn't help you, in this example, to find something in the Emacs manuals - something that isn't there. IOW, hardly a demonstration of the failings of Info indexing. > If one prefers a traditional manual, the use-Google approach > can be *really* annoying, as it tends to throw up all sorts of > trash, and I understand the annoyance. Really, I do. Do you also understand that it's not about a choice *between* "traditional manual" and "the use-Google approach"? That's a false choice. No one is out to replace googling. There can be more than one tool in your tool belt, just as there is more than one book in the library. Choose both, not between. Sticking with the library, your little anecdote is like this one: I went to the library and looked in the index of a book for information about TVs. I didn't find anything about TVs there. I even searched every page of that book, but I found nothing about TVs. Damn! Then I asked the librarian for help, and s?he pointed me (immediately!) to plenty of magazines and books that talk about TVs. Clearly that first book's index is total crap - utterly a failure. > But what can I say? It often works way better, Yes, of course it works better at some things - many things. Most things. It indexes the entire web! Everyday. Very well. That's really not the point. Is it better at navigating the Emacs manuals? Is it better at helping you find information in the Emacs manuals? Those are reasonable & interesting questions that might lead to our improving a user's experience with the manuals. But arguing that googling is powerful is a waste of time. And telling us that if you google poorly you can end up=20 with noise is also a waste of time. We all google. We all know its strengths and weaknesses. > we should be exploiting this technology What's your proposition for exploiting the technology? I exploit it everyday, when I search for things. Just what did you have in mind? Google and other search engines already index our manuals for full-text search. You can already use web search to find information in the manuals. That's not a missing feature. What is missing in the web versions of the manuals has already been discussed somewhat. Some of what's missing could perhaps be provided, even including Info-style navigation and indexing perhaps. And even including the feature of *being inside Emacs*, if you browse and search the web using Emacs. I don't do the latter, personally. But if I end up in the web manual from some Internet search, I do sometimes copy the node name and then yank it into my local Emacs manual (Info), for further navigation and investigation. (That's essentially the manual inverse of what the code does that I sent a couple days ago, which makes the link in the other direction, from Info node to web-manual node.) And I don't move back to Info inside Emacs just because Info has better navigation and investigation features for the manuals (for now, at least). I do it also because *Emacs is where I want to be* when I am consuming information about Emacs - because I use the information with Emacs. That feature of local Info should also be a no-brainer, when it comes to the Emacs manuals: you want to *use* the information about Emacs for Emacs, with Emacs. > rather than limiting ourselves to the > not-particularly-successful tactic of asking people to > send us bug reports and fixes for our manuals. Again, a strange, black-&-white either-or. No one has argued that we should limit ourselves to soliciting bug reports and fixes for the manuals. But had you found that there *was* a section of the manual that covered composite glyphs the way you wanted, and had you felt it was not easy to find that section using `i', then I would hope that you would take the time to suggest an index entry or two for it. You can do both: file bug reports and search the Internet.