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: Wed, 6 Nov 2002 07:30:16 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <20021106123016.GA20637@gnu.org> References: <200211011623.gA1GNAL03601@rum.cs.yale.edu> <5xznsnvabl.fsf@kfs2.cua.dk> <5x7kfqoogr.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 1036587012 27270 80.91.224.249 (6 Nov 2002 12:50:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2002 12:50:12 +0000 (UTC) Cc: 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 189PdD-00075H-00 for ; Wed, 06 Nov 2002 13:50:04 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189Pli-000166-00 for ; Wed, 06 Nov 2002 13:58:50 +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 189Pa0-0000Ip-00; Wed, 06 Nov 2002 07:46:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189PKA-0001gJ-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 07:30:22 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189PK8-0001g7-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 07:30:22 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189PK8-0001g1-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 07:30:20 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 189PK4-0005oQ-00; Wed, 06 Nov 2002 07:30:16 -0500 Original-To: "Kim F. Storm" Content-Disposition: inline In-Reply-To: <5x7kfqoogr.fsf@kfs2.cua.dk> User-Agent: Mutt/1.3.28i Blat: Foop 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:9179 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9179 On Wed, Nov 06, 2002 at 01:46:28PM +0100, Kim F. Storm wrote: > > Hmmm, well it looks _less_ bad: now the text is all in a properly- > > indented, but absurdly narrow column. > > Weren't they in an absurdly narrow column already ? ;-) Indeed, but pushed over to the right side of the window by the long node name, which made it look vaguely natural (though still bad). Luckily this generally only seems to be the case in the dir menu, and that's the one that it's OK to modify... > > 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 > > > > seems to work alright. > > Maybe. If you send me some misc dir files which have particular problems, > I can probably do a better job at getting this right. I'm just using my normal dir menu, which is emacs' dir merged with the (auto-generated) debian dir file. If you don't have a debian system, I can send you a copy of my file. I did try out the above lisp by hand on a bunch of entries in my dir menu, and it worked every time (though there's always an exception I suppose). 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 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). -Miles -- P.S. All information contained in the above letter is false, for reasons of military security.