From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John J Foerch Newsgroups: gmane.emacs.devel Subject: Re: Outline mode Date: Tue, 04 Sep 2007 11:58:31 -0400 Message-ID: <87wsv6ifrs.fsf@earthlink.net> 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 1188921032 15536 80.91.229.12 (4 Sep 2007 15:50:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Sep 2007 15:50:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 04 17:50:31 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 1ISafb-0000sr-Dw for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2007 17:50:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISafZ-0004q0-Uc for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2007 11:50:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISafW-0004pY-PF for emacs-devel@gnu.org; Tue, 04 Sep 2007 11:50:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ISafW-0004p6-3W for emacs-devel@gnu.org; Tue, 04 Sep 2007 11:50:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISafV-0004ov-P1 for emacs-devel@gnu.org; Tue, 04 Sep 2007 11:50:21 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ISafU-0003XX-W0 for emacs-devel@gnu.org; Tue, 04 Sep 2007 11:50:21 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISafJ-0008Un-1K for emacs-devel@gnu.org; Tue, 04 Sep 2007 17:50:09 +0200 Original-Received: from dialup-4.158.192.233.dial1.chicago1.level3.net ([4.158.192.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 17:50:09 +0200 Original-Received: from jjfoerch by dialup-4.158.192.233.dial1.chicago1.level3.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Sep 2007 17:50:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 63 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialup-4.158.192.233.dial1.chicago1.level3.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) Cancel-Lock: sha1:5D9d9fEAtgl2zGDTKW5p0Y9ggSQ= X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) 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:77745 Archived-At: Stefan Monnier writes: > > 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. > > 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 Sure. I want the heading line of a collapsed entry to be editable independent of the entry. The newline at the end of the header should belong to the header, so when point is there, there can be no funny surprises about doing things like backspace. The reason I don't like the idea of modifying move-end-of-line, or rebinding my C-e key in outline-mode, is that that command is only one of many possible ways to put point on that character. I would find that very inconsistent indeed. If I may go back to the implementation side of it for a minute, I would like to share some thoughts I had this morning. When I think of the logical parts out of which an outline is made, I think of blocks composed of two parts: headers and entries. But the current implementation is in terms of blocks composed of three parts: a header (with no newline), an entry, and a terminating newline. The current implementation was made necessary because the code that places the ellipsis always places it at the point of the invisible text. Thus in order to have the effect of the ellipsis being on the same visual line as the header, you have to say that the newline after the header is actually part of the entry, and you have to leave the final newline from the entry unhidden. An invisibility-spec looks like '(outline . t). The t signifies that an ellipsis will be displayed in place of the invisible text. My idea now is to add a feature to the invisibility code that lets you give a function in place of that t. The function would be called with two arguments--the region being made invisible--and the function would return the point where the ellipsis should be displayed. This would let outline-mode have an option to leave the header's newline visible, and hide the final newline of the entry. The function given in the invisibility-spec would return the location of the header's newline as the location to display the ellipsis. --John