From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: info invisible changes Date: Wed, 06 Nov 2002 10:11:41 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211061511.gA6FBfL02691@rum.cs.yale.edu> References: <200211011623.gA1GNAL03601@rum.cs.yale.edu> <5xznsnvabl.fsf@kfs2.cua.dk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036596397 8961 80.91.224.249 (6 Nov 2002 15:26:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2002 15:26:37 +0000 (UTC) Cc: storm@cua.dk (Kim F. Storm), "Stefan Monnier" , 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 189S4S-0002Ii-00 for ; Wed, 06 Nov 2002 16:26:20 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189SD1-0004gA-00 for ; Wed, 06 Nov 2002 16:35:11 +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 189S3v-0007EJ-00; Wed, 06 Nov 2002 10:25:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189RqY-0002ZJ-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 10:11:58 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189RqR-0002Up-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 10:11:55 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189RqQ-0002Qv-00; Wed, 06 Nov 2002 10:11:51 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA6FBfL02691; Wed, 6 Nov 2002 10:11:41 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Miles Bader 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:9190 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9190 > Hmmm, well it looks _less_ bad: now the text is all in a properly- > indented, but absurdly narrow column. > > I agree with Stefan that the text should be refilled in the top-level > dir node -- it's special because it contains much more hidden text than > a normal node, and looks especially bad without refilling, and also it's > not connected with a file (it's generated), so it's safe to modify. It's also special because it tends to itself not be properly aligned/filled because each entry can come from a different dir file (and also from different .texi files (via their .info and install-info)) so the alignment of text is often strange. to start with, unless all the dir files have been manually edited. In most other menus, the entries are of the form '* blabla::' and there is thus nothing to hide, really. > Morever, the format of the menu entries seems regular enough that > finding the bounds required to fill/reindent; something like > > (goto-char START-OF-MENU-ENTRY-TEXT) > (forward-sentence) > (while (looking-at ".*\n[ \t]+[^ \t]") > (forward-sentence)) > ;; point is now at END-OF-MENU-ENTRY-TEXT I'd use (re-search-forward "^[^ \t]"). I believe that's what I use in Info-remove-duplicates. > BTW, on the issue of whether it's OK to modify the buffer contents, I think > it should be OK; (buffer-file-name) is always nil in the *info* buffer, after It now indeed is nil. It used to be the case that it sometimes was nil sometimes not. > all. I think a lot of this stuff would become _much_ simpler if you could > must munge the buffer instead of using invisible/display properties (with all > their associated oddities), perhaps using text properties to store the > necessary non-displayed info instead of parsing the buffer for it -- of > course this would perhaps be a bigger change, since you'd have to modify the > various info-getting functions too, but I don't see why it would be _that_ > big a job (presumably the modified code would support both text-property > stored info and buffer-parsing, for backward compatibility). I disagree. Especially since it's all customizable, it's easier and safer to keep only one buffer-format and change the appearance via properties. Stefan