From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Outline mode Date: Tue, 04 Sep 2007 10:27:08 -0400 Message-ID: References: <87odgnbr9q.fsf@earthlink.net> <87fy1zb77e.fsf@earthlink.net> <871wdicmx9.fsf@earthlink.net> <87vear6u8v.fsf@earthlink.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188916039 29061 80.91.229.12 (4 Sep 2007 14:27:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Sep 2007 14:27:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: John J Foerch Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 04 16:27:18 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ISZN8-00047d-1I for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2007 16:27:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISZN6-0002ms-Bh for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2007 10:27:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISZN2-0002mM-VH for emacs-devel@gnu.org; Tue, 04 Sep 2007 10:27:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ISZN0-0002mA-IF for emacs-devel@gnu.org; Tue, 04 Sep 2007 10:27:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISZN0-0002m7-Cl for emacs-devel@gnu.org; Tue, 04 Sep 2007 10:27:10 -0400 Original-Received: from x-132-204-254-144.xtpr.umontreal.ca ([132.204.254.144] helo=ceviche.home) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ISZMz-0008Lt-WC for emacs-devel@gnu.org; Tue, 04 Sep 2007 10:27:10 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 28DFCB40B5; Tue, 4 Sep 2007 10:27:08 -0400 (EDT) In-Reply-To: <87vear6u8v.fsf@earthlink.net> (John J. Foerch's message of "Mon\, 03 Sep 2007 22\:26\:40 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Linux 2.6 (newer, 3) 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:77744 Archived-At: > Okay, now that I know that outline-mode's behavior is not a bug (only > a peave), I agree that my side-stepping the invisibility-spec ellipsis > is a hack. Yet I don't like this idea of changing the movement > commands to make it more difficult to move point to certain > characters, either. Check the docstring of move-end-of-line and you'll see that the current behavior has a reasonable justification: it tries to ignore newlines that do not correspond to a screen newline, e.g. newlines that are in the middle of a `display' property showing a picture, or newlines that are `invisible' specifically to give the illusion of having a single line. But I agree that in the case of outline-mode, the move-end-of-line behavior is not quite right: it should stop at the end of the heading since it is visually the end of the line (with an "inaccessible" ellipsis appended to it). If people aree with this assessment, we can adjust the behavior of move-end-of-line accordingly. > The basic thing that I want to implement is to make outline mode > collapse in a way that fits with how I naturally think about > outlines--the header is one complete line that can be edited as > normally as you would edit any line in any text file, and the entry > consists of all the lines below it, until the next header. The > ellipsis code related to invisibility-spec does not accomodate this > well, because it would place the ellipsis on the line after the > header--clearly not a nice looking format. That is what led me to > implement separate ellipsis handling in outline-mode--a clear mistake. > So is the following an agreeable solution? Modify the > invisibility-spec code to allow the ellipsis to be placed one > character before the invisible text, via a third parameter in > invisibility-spec. This would allow the entries to be collapsed in > the way I described, while still allowing the ellipsis to appear on > the same line as the header, and without the hack work-arounds. > This still has the problem of compatibility with derived modes, some > of which (like org-mode if I recall) explicitly depend on the header's > newline being invisible, and the entry's newline being visible. For > this problem, I suggest writing whatever abstractions are necessary in > outline-mode, so the point-arithmetic in the derived modes can be > replaced by function calls, and thus accomodate both ways of hiding > entries. I don't understand what you want. Can you try and express it in terms of user-level visible behavior rather than in terms of low-level implementation details? Stefan