From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: invisible Date: Thu, 29 Nov 2007 11:15:40 +0100 Message-ID: <474E914C.4070407@gmx.at> References: <20040225.150142.12214540.kazu@iijlab.net> <200402282128.i1SLSuY15359@raven.dms.auburn.edu> <200402290224.i1T2Oip15705@raven.dms.auburn.edu> <87sl3fdqs3.fsf@escher.local.home> <87zlxc5r2f.fsf@escher.local.home> <474059CD.1060107@gmx.at> <87r6ihi1z7.fsf@escher.local.home> <4746E2CF.4010604@gmx.at> <87k5o8q0y5.fsf@escher.local.home> <4747312D.7020605@gmx.at> <87fxywpuuy.fsf@escher.local.home> <47474B8C.9020806@gmx.at> <87bq9kpnqd.fsf@escher.local.home> <4747EFE8.5090405@gmx.at> <474A7CF6.8030802@gmx.at> <474B19DB.6030803@gmx.at> <474C65FF.3070403@gmx.at> <87r6ia3qfr.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1196332550 26027 80.91.229.12 (29 Nov 2007 10:35:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2007 10:35:50 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 29 11:35:59 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 1IxgkR-00044V-2Y for ged-emacs-devel@m.gmane.org; Thu, 29 Nov 2007 11:35:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxgkB-0000Be-Bi for ged-emacs-devel@m.gmane.org; Thu, 29 Nov 2007 05:35:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ixgk4-00008u-SR for emacs-devel@gnu.org; Thu, 29 Nov 2007 05:35:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ixgk3-000068-Cn for emacs-devel@gnu.org; Thu, 29 Nov 2007 05:35:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ixgk3-00005i-0G for emacs-devel@gnu.org; Thu, 29 Nov 2007 05:35:35 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Ixgk2-0005RQ-Gf for emacs-devel@gnu.org; Thu, 29 Nov 2007 05:35:34 -0500 Original-Received: (qmail invoked by alias); 29 Nov 2007 10:35:33 -0000 Original-Received: from N725P030.adsl.highway.telekom.at (EHLO [62.47.34.158]) [62.47.34.158] by mail.gmx.net (mp042) with SMTP; 29 Nov 2007 11:35:33 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19VWEFqGBpVgDKApBnzwCDU2LMFoCsiV6SlsmvxZl MbL7UTr41pPR+6 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <87r6ia3qfr.fsf@escher.local.home> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: 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:84291 Archived-At: > I'm afraid it did not, which puzzles me in view of the confidence you > expressed. I wonder if we did something different again. Yes and no. I've been experimenting with a different approach to make parts of lines invisible. Everything you did was correct. I'm afraid the problem cannot be solved satisfactorily without using the rear-nonsticky property. In fact the "bug" happens _before_ we can see it. Consider the following configuration where the "\n" are visible newlines, the "(\n)" invisible rear-sticky ones, dots are plain visible non-newline text, and "^" indicates the position of `point': .....\n .....(\n).....(\n).....(\n).....(\n).....\n ^.....\n C-p now should move to .....\n .....(\n).....(\n).....(\n).....(\n)^.....\n .....\n but the point-setting in scan_newline really moves to .....\n .....(\n).....(\n).....(\n).....^(\n).....\n .....\n which _appears_ correct because the newline doesn't appear on screen. Recall that the point-setting mechanism doesn't permit to position `point' after the invisible newline because the text property is rear-sticky. Hitting C-p again first invokes (forward-line -1) to move `point' to the beginning of the previous line as .....\n .....(\n).....(\n)^.....(\n).....(\n).....\n .....\n but the point-setting mechanism in scan_newline again corrects this to .....\n .....(\n).....^(\n).....(\n).....(\n).....\n .....\n The next C-p gets us to .....\n ^.....(\n).....(\n).....(\n).....(\n).....\n .....\n because we now are after a visible newline and our `goal-column' is still zero. I think we first have to specify what we really want and then fix this accordingly. I can think of the following alternatives: (1) Provide for disabling the point adjustment mechanism in scan_newline. The disadvantage of this approach is that `point' may appear after rear-sticky invisible text and doing a self-insert there won't show the character. (2) Make self-insertion after rear-sticky invisible (intangible, ...) text by default _not_ inherit the invisibility property. Intuitively, this should do the right thing but the outcome would be different for not self-inserting commands that try to insert text at `point'. (3) Use the rear-nonsticky property and live with the fact that insertions may occur on either end of the invisible text depending on whether you arrived at the corresponding screen position either by moving forwards or backwards. As Stefan said we could ameliorate this when using ellipses. However, what should `forward-char' do with invisible text replaced by an ellipis and `point' immediately before it: text^...text Should it go here text...^text or here text...t^ext