From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: invisible Date: Fri, 23 Nov 2007 13:24:28 +0100 Message-ID: <87r6ihi1z7.fsf@escher.local.home> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1195820723 8087 80.91.229.12 (23 Nov 2007 12:25:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Nov 2007 12:25:23 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 23 13:25: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 1IvXb5-0003bQ-E4 for ged-emacs-devel@m.gmane.org; Fri, 23 Nov 2007 13:25:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvXar-00057L-20 for ged-emacs-devel@m.gmane.org; Fri, 23 Nov 2007 07:25:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IvXan-000570-C5 for emacs-devel@gnu.org; Fri, 23 Nov 2007 07:25:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IvXam-00056c-Pk for emacs-devel@gnu.org; Fri, 23 Nov 2007 07:25:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvXam-00056T-My for emacs-devel@gnu.org; Fri, 23 Nov 2007 07:25:08 -0500 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 1IvXam-0002GR-Dr for emacs-devel@gnu.org; Fri, 23 Nov 2007 07:25:08 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IvXaY-0003Gy-MB for emacs-devel@gnu.org; Fri, 23 Nov 2007 12:24:54 +0000 Original-Received: from i5387de1d.versanet.de ([83.135.222.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2007 12:24:54 +0000 Original-Received: from Stephen.Berman by i5387de1d.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Nov 2007 12:24:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 112 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387de1d.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) 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:83947 gmane.emacs.pretest.bugs:20345 Archived-At: Sorry for the late response. On Sun, 18 Nov 2007 16:27:09 +0100 martin rudalics wrote: >>>>(put-text-property 6 7 `invisible t) >>>>(put-text-property 12 13 `invisible t) >>>>(put-text-property 18 19 `invisible t) >>>>(put-text-property 24 25 `invisible t) >>>>(put-text-property 30 31 `invisible t) > > These will cause problems with `forward-line'. > > I'd propose to use > > (add-text-properties 6 7 '(invisible t rear-nonsticky t)) > (add-text-properties 12 13 '(invisible t rear-nonsticky t)) > (add-text-properties 18 19 '(invisible t rear-nonsticky t)) > (add-text-properties 24 25 '(invisible t rear-nonsticky t)) > (add-text-properties 30 31 '(invisible t rear-nonsticky t)) > > instead. > >>>>C-p beginning of line4. Why did we skip line5? >>>>C-p beginning of line2. Skipped line3. > > See above. Verify by running (forward-line -1) on these. Your results > may differ according to the value of `track-eol'. With the rear-nonsticky property set to t C-p does not skip lines 5 and 3, i.e. it DTRT. With (forward-line -1) there is also no line skipping, but this is also the case without setting the rear-nonsticky property to t, i.e., I see no difference, in contrast to C-p. The value of track-eol is nil (the default). So I am not sure what problems you mean. >>>This behavior still exists in GNU Emacs 23.0.50.4 (i686-pc-linux-gnu, >>>GTK+ Version 2.12.0) of 2007-11-09 on escher.[1] In addition, starting >>>with the cursor at (point-min), the line number indicator in the mode >>>line displays L1, and it continues to display L1 as you advance either >>>by C-n or by C-f until it reaches the `l' of `line7', then it changes to >>>L7. From there if you type C-b moving point to just after `6', the mode >>>line displays L6. Now continuing backwards either by C-p or C-b the >>>mode line usually continues to display L6, even at (point-min). Typing >>>C-b again here then changes the display to L1. > > We have been discussing this at the beginning of this year but I don't > recall the thread. I seem to recall that Emacs tries to optimize line > number calculations as long as the buffer is not modified. I don't recall this discussion, but in any case Emacs normally does update the line number display when the cursor moves to another line, which does not involve buffer modification, so I don't see why invisibility should make a difference here. >> In current development Emacs, the cursor stays put, i.e., C-p is a no-op >> here; the same goes for every position in line 3, except the beginning >> of the line: here C-p goes to the beginning of line 1 (the parenthetical >> comment doesn't make sense, unless it is a typo for line 1, or maybe he >> means the mode line should display L2 instead of L3, even though the >> cursor stays put). > > This seems like a bug in `line-move-finish', please try the attached > patch (untested). With your patch typing C-p, with the cursor at any position in line 3 but the beginning of the line, moves the cursor to the beginning of line 3, i.e., does the same thing as C-a. I think I would have expected it to put the cursor on line 1. (At the beginning of line 3 the behavior is as before, C-p goes to the beginning of line 1.) >>>At the beginning of line 3, C-e goes to "i" in line 3. >>> (should go to the end of line 3) >> >> >> In current development Emacs, the cursor goes to the end of line 1 >> (anywhere else on line 3, C-e goes to the end of line 3). On the other >> hand, C-a at the beginning of line 3 goes to "i" in line 3 (elsewhere it >> goes to the beginning of the line, so that repeatedly typing C-a >> starting from the beginning of line 3 makes the cursor oscillate between >> the first and second columns of the line). >> >> >>>(2) If line-move-ignore-invisible is t: >>> >>>At the end of line 1, C-n goes to the beginning of line 3. >>> (should go to the end of line 3) >>>At the end of line 4, C-p goes to the beginning of line 3. >>> (should go to the end of line 3) >>>At the beginning of the line 3, C-e goes to "i" in line 3. >>> (should go to the end of line 3) > > There's likely also a bug in `line-move-to-column': `move-to-column' > apparently skips invisible text (I didn't find any documentation for > that). I tried to fix it in a really awkward way in the same patch. Is this patch intended to fix the behavior I described above (2)? For that case, if I do as you suggested above and set both invisible and rear-nonsticky to t, then no patch is needed: with these properties both C-e and C-a DTRT at all positions. But leaving rear-nonsticky nil, the misbehavior remains even with your patch. Summarizing, it appears that rear-nonsticky should be set to t when a position is given the invisible property. In particular, facemenu-set-invisible should be changed accordingly, otherwise the menu choice Edit->Text Properties->Special Properties->Invisible admits the observed motion misbehavior. (But I don't know if there are other cases where facemenu-set-invisible should leave the invisible position rear-sticky.) This still does not fix the problem with C-p at positions other than the beginning of the line after an invisible line, but your patch for that also results in unexpected behavior. Steve Berman