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 20:09:39 -0400 Message-ID: <873axu6kho.fsf@earthlink.net> References: <87odgnbr9q.fsf@earthlink.net> <87fy1zb77e.fsf@earthlink.net> <871wdicmx9.fsf@earthlink.net> <59224.128.165.123.18.1188946347.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188950502 20934 80.91.229.12 (5 Sep 2007 00:01:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2007 00:01:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 02:01:42 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 1ISiKt-0001hx-Bi for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2007 02:01:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISiKr-0007Jq-Rj for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2007 20:01:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISiKo-0007JF-QW for emacs-devel@gnu.org; Tue, 04 Sep 2007 20:01:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ISiKn-0007I4-8G for emacs-devel@gnu.org; Tue, 04 Sep 2007 20:01:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISiKm-0007Hu-VB for emacs-devel@gnu.org; Tue, 04 Sep 2007 20:01:28 -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 1ISiKm-0005Z3-Co for emacs-devel@gnu.org; Tue, 04 Sep 2007 20:01:28 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISiKi-00050p-QC for emacs-devel@gnu.org; Wed, 05 Sep 2007 02:01:24 +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 ; Wed, 05 Sep 2007 02:01:24 +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 ; Wed, 05 Sep 2007 02:01:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 48 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:AffM43xxIDnSAG2HdSaQQBnNA0g= 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:77803 Archived-At: "Davis Herring" writes: > > Agreed. With that change, the place where C-e goes now could be reached > by C-n C-b (with `line-move-ignore-invisible' non-nil, which it is in > Outline mode). Without it, the place where C-e would go with it cannot be > reached except by something as complicated as C-s C-q C-j C-b, or M-x > search-forward RET C-q C-j RET to avoid unhiding the entry. > > With that change, is there even an issue anymore? I'm not sure I > understand all of the original complaint. > > Davis > This would only introduce more inconsistency to what is already there. In my original posting, I only gave C-e as an example of how one might get to the location I was talking about, not as the only command I ever use to put point in that location. The problem is not with C-e. The problem is that the newline after the header is part of the entry, and the newline before the next header is not part of the entry. I would like an option to have it the other way around, and I'm willing to go so far as to write a new mode so I can have it that way. I achieved the effect I want in the patch I posted, by an admitted hack--bypassing the low-level ellipsis code, and implementing new ellipsis code in outline.el. But to implement this feature correctly, the low-level ellipsis code, mainly in xdisp.c, if I am not mistaken, would need a new feature added. The new feature is to allow invisibility-spec to control where the ellipsis would be displayed, instead of always displaying it at the point of the invisible text. If adding this feature to the low level ellipsis code is too complicated, I would rather live with my hack method in my .emacs than to see the behavior of C-e changed. That said, I am studying the low-level ellipsis code to see what I can make of it. I'm not very familiar with emacs' C codebase, so it all looks a bit hieroglyphic to me at the moment. Thanks to everyone who has taken an interest in this problem. I appreciate it very much. It is a more complicated problem than I originally thought, but I would rather take a longer time and fix the fundamental problem in the ellipsis code than add a cosmetic hack to outline.el or move-end-of-line. --John