From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: info invisible changes Date: 05 Nov 2002 13:08:02 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200211011623.gA1GNAL03601@rum.cs.yale.edu> Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036470688 9587 80.91.224.249 (5 Nov 2002 04:31:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 04:31:28 +0000 (UTC) Cc: emacs-devel@gnu.org, emacs-pretest-bug@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 188vN8-0002UV-00 for ; Tue, 05 Nov 2002 05:31:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 188vUx-0000Ac-00 for ; Tue, 05 Nov 2002 05:39:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 188vM7-0001nM-00; Mon, 04 Nov 2002 23:30:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188v10-000389-00 for emacs-devel@gnu.org; Mon, 04 Nov 2002 23:08:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188v0w-00036f-00 for emacs-devel@gnu.org; Mon, 04 Nov 2002 23:08:32 -0500 Original-Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by monty-python.gnu.org with esmtp (Exim 4.10) id 188v0v-00032I-00; Mon, 04 Nov 2002 23:08:29 -0500 Original-Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id gA548Cl07337; Tue, 5 Nov 2002 13:08:12 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id gA5485H28946; Tue, 5 Nov 2002 13:08:08 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id gA5483221647; Tue, 5 Nov 2002 13:08:05 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id gA5482B05096; Tue, 5 Nov 2002 13:08:03 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id E8C7536FF; Tue, 5 Nov 2002 13:08:02 +0900 (JST) Original-To: "Stefan Monnier" System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200211011623.gA1GNAL03601@rum.cs.yale.edu> Original-Lines: 164 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9122 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9122 "Stefan Monnier" writes: > Can you decode for me the following email you sent ;-) ? Whoops, sorry; maybe that's why I didn't any response (until I looked just now, I didn't even realize that it had gotten encoded into some wierd encoding, base64'd, etc!)... Here's the original mail, sans byte-code strings: Hi Kim, I see you put in your info changes. It does look nicer (cleaner), but there are some problems: When I do `Memacs' from the top-level dir (with point at the beginning of the buffer), I get the following error: Debugger entered--Lisp error: (error "No such anchor in tag table or node in tag table or file: The extensible self-documenting text editor") signal(error ("No such anchor in tag table or node in tag table or file: The extensible self-documenting text editor")) error("No such anchor in tag table or node in tag table or file: %s" "The extensible self-documenting text editor") byte-code(...) Info-find-node-2(nil "The extensible self-documenting text editor" nil) Info-find-node(nil "The extensible self-documenting text editor") Info-goto-node("The extensible self-documenting text editor" nil) Info-menu("Emacs" nil) call-interactively(Info-menu) [Note that the "The extensible ..." is the descriptive text for the `Emacs' menu line, so apparently the `M' command is getting confused about how things are formatted.] There are some other, more minor problems with this: (1) The dir file (and presumably other info menus) I have was formatted assuming that no text would be hidden, so in some cases, the invisible text results in a very wierd looking display. Here's an example display from my *info* dir node (these are all debian entries): --- begin quote --- * CVS Concurrent Versions System * CVS client/server Describes the client/server protocol used by CVS. * gcc-295 The GNU Compiler Collection (Version 2.95.x). * Gdb The GNU debugger. * Gdb-Internals The GNU debugger's internals. --- end quote --- Here's the text as it appears without invisible regions: --- begin quote --- * CVS: (cvs). Concurrent Versions System * CVS client/server: (cvsclient). Describes the client/server protocol used by CVS. * gcc-295: (gcc-295). The GNU Compiler Collection (Version 2.95.x). * Gdb: (gdb). The GNU debugger. * Gdb-Internals: (gdbint). The GNU debugger's internals. --- end quote --- From the above, it seems that your change also removes some whitespace, because just difference can't be accounted for by just making the node-name and puncutation invisible. (2) Cursor movement is `wierd' around the invisible text region. For instance, taking one of the menu lines from above: --- begin quote --- * gcc-295 The GNU Compiler --- end quote --- when I use C-f to move forward from the beginning of the line, everything's OK until point is before the `5'. If I hit C-f then, point jumps to being before the `T', when I expected it to move to just after the `5'. If I then hit C-f again, the cursor doesn't move, `sticking' at the point before the `T'; another C-f then moves forward as expected. I thought these sorts of problems were supposed to be generally fixed these days (well, C-n/C-p are still fucked I think, but they're a separate case), so perhaps there's something odd with the way you're setting up your invisible text. (3) In the gcc-2.95 info doc, there's a node (`(gcc-295)G++ and GCC') that contains the following text: --- begin quote --- that you get better object code, and better debugging information. The GNU debugger, GDB, works with this information in the object code to give you comprehensive C++ source-level editing capabilities (*note C and C++: (gdb.info)C.). --- end quote --- your *note hack turns it into: --- begin quote --- that you get better object code, and better debugging information. The GNU debugger, GDB, works with this information in the object code to give you comprehensive C++ source-level editing capabilities (see C and C++.info)C.). --- end quote --- (4) The wrapping problem happens with *note tags too; often it's fairly benign (a line that's unusually short because of invisible'd text), but sometimes it gets a bit uglier; e.g. the original: --- begin quote --- order to be compiled,and also requires the header files for the target's thread library if you want thread support. *Note Cross-Compilers and Header Files: Cross Headers, for discussion about header files issues for cross-compilation. --- end quote --- turns into [note the wrapped line]: --- begin quote --- order to be compiled,and also requires the header files for the target's thread library if you want thread support. See Cross-Compilers and Header Files, for discussion about header files issues for cross-compilation. --- end quote --- (5) Cursor movement around the `See' is wierd, but I guess that's something you can do much about. (6) Ah, I just saw another misformatted menu entry; the original: --- begin quote --- * gcc-3.2: (gcc-3.2). The GNU Compiler Collection (Version 3.2). * gccint-3.2: (gccint-3.2). Internals of the GNU Compiler Collection (Version 3.2). --- end quote --- turns into: --- begin quote --- * gcc-3.2 2). The GNU Compiler Collection (Version 3.2). * gccint-3.2 2). Internals of the GNU Compiler Collection (Version 3.2). --- end quote --- Anyway, I basically like it, it's noticably easier to read than the old style. -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia