From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: invisible Date: Sun, 18 Nov 2007 16:27:09 +0100 Message-ID: <474059CD.1060107@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020602020800010902020809" X-Trace: ger.gmane.org 1195399622 8543 80.91.229.12 (18 Nov 2007 15:27:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2007 15:27:02 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 18 16:27:06 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 1Itm2x-0001IO-1K for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2007 16:27:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Itm2d-0000pj-O0 for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2007 10:26:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Itm2a-0000pO-1C for emacs-devel@gnu.org; Sun, 18 Nov 2007 10:26:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Itm2S-0000nQ-SZ for emacs-devel@gnu.org; Sun, 18 Nov 2007 10:26:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Itm2S-0000nN-O8 for emacs-devel@gnu.org; Sun, 18 Nov 2007 10:26:24 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Itm2Q-0000Pw-LJ for emacs-devel@gnu.org; Sun, 18 Nov 2007 10:26:24 -0500 Original-Received: (qmail invoked by alias); 18 Nov 2007 15:26:15 -0000 Original-Received: from N932P009.adsl.highway.telekom.at (EHLO [62.47.60.105]) [62.47.60.105] by mail.gmx.net (mp058) with SMTP; 18 Nov 2007 16:26:15 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18JzMo3omMJiLNywhvwbj2HLF2M2ZXiWmw/HsrCEd cpGOdhSLMIMlCN User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <87zlxc5r2f.fsf@escher.local.home> X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 1) 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:83540 gmane.emacs.pretest.bugs:20304 Archived-At: This is a multi-part message in MIME format. --------------020602020800010902020809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >>>(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'. >>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. > 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). >>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. --------------020602020800010902020809 Content-Type: text/plain; name="simple.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="simple.patch" KioqIHNpbXBsZS5lbC5+MS44ODgufglTYXQgTm92IDEwIDA5OjIzOjIwIDIwMDcNCi0tLSBz aW1wbGUuZWwJU3VuIE5vdiAxOCAxNjowMjo0MiAyMDA3DQoqKioqKioqKioqKioqKioNCioq KiAzODYyLDM4NjggKioqKg0KICAJICAgICAoc2F2ZS1leGN1cnNpb24NCiAgCSAgICAgICA7 OyBMaWtlIGVuZC1vZi1saW5lIGJ1dCBpZ25vcmVzIGZpZWxkcy4NCiAgCSAgICAgICAoc2tp cC1jaGFycy1mb3J3YXJkICJeXG4iKQ0KISAJICAgICAgICh3aGlsZSAoYW5kIChub3QgKGVv YnApKSAoaW52aXNpYmxlLXAgKHBvaW50KSkpDQogIAkJIChnb3RvLWNoYXIgKG5leHQtY2hh ci1wcm9wZXJ0eS1jaGFuZ2UgKHBvaW50KSkpDQogIAkJIChza2lwLWNoYXJzLWZvcndhcmQg Il5cbiIpKQ0KICAJICAgICAgIChwb2ludCkpKSkNCi0tLSAzODYyLDM4NjkgLS0tLQ0KICAJ ICAgICAoc2F2ZS1leGN1cnNpb24NCiAgCSAgICAgICA7OyBMaWtlIGVuZC1vZi1saW5lIGJ1 dCBpZ25vcmVzIGZpZWxkcy4NCiAgCSAgICAgICAoc2tpcC1jaGFycy1mb3J3YXJkICJeXG4i KQ0KISAJICAgICAgICh3aGlsZSAoYW5kIGxpbmUtbW92ZS1pZ25vcmUtaW52aXNpYmxlDQoh IAkJCSAgIChub3QgKGVvYnApKSAoaW52aXNpYmxlLXAgKHBvaW50KSkpDQogIAkJIChnb3Rv LWNoYXIgKG5leHQtY2hhci1wcm9wZXJ0eS1jaGFuZ2UgKHBvaW50KSkpDQogIAkJIChza2lw LWNoYXJzLWZvcndhcmQgIl5cbiIpKQ0KICAJICAgICAgIChwb2ludCkpKSkNCioqKioqKioq KioqKioqKg0KKioqIDM5NDAsMzk0OCAqKioqDQogIFRoaXMgZnVuY3Rpb24gd29ya3Mgb25s eSBpbiBjZXJ0YWluIGNhc2VzLA0KICBiZWNhdXNlIHdoYXQgd2UgcmVhbGx5IG5lZWQgaXMg Zm9yIGBtb3ZlLXRvLWNvbHVtbicNCiAgYW5kIGBjdXJyZW50LWNvbHVtbicgdG8gYmUgYWJs ZSB0byBpZ25vcmUgaW52aXNpYmxlIHRleHQuIg0KISAgIChpZiAoemVyb3AgY29sKQ0KISAg ICAgICAoYmVnaW5uaW5nLW9mLWxpbmUpDQogICAgICAobW92ZS10by1jb2x1bW4gY29sKSkN Cg0KICAgICh3aGVuIChhbmQgbGluZS1tb3ZlLWlnbm9yZS1pbnZpc2libGUNCiAgCSAgICAg KG5vdCAoYm9scCkpIChpbnZpc2libGUtcCAoMS0gKHBvaW50KSkpKQ0KLS0tIDM5NDEsMzk1 NiAtLS0tDQogIFRoaXMgZnVuY3Rpb24gd29ya3Mgb25seSBpbiBjZXJ0YWluIGNhc2VzLA0K ICBiZWNhdXNlIHdoYXQgd2UgcmVhbGx5IG5lZWQgaXMgZm9yIGBtb3ZlLXRvLWNvbHVtbicN CiAgYW5kIGBjdXJyZW50LWNvbHVtbicgdG8gYmUgYWJsZSB0byBpZ25vcmUgaW52aXNpYmxl IHRleHQuIg0KISAgIChjb25kDQohICAgICgoemVyb3AgY29sKQ0KISAgICAgKGJlZ2lubmlu Zy1vZi1saW5lKSkNCiEgICAgKGxpbmUtbW92ZS1pZ25vcmUtaW52aXNpYmxlDQogICAgICAo bW92ZS10by1jb2x1bW4gY29sKSkNCisgICAgKHQNCisgICAgIDs7IFRlZGlvdXMuDQorICAg ICAoc2F2ZS1yZXN0cmljdGlvbg0KKyAgICAgICAobmFycm93LXRvLXJlZ2lvbiAobGluZS1i ZWdpbm5pbmctcG9zaXRpb24pIChsaW5lLWVuZC1wb3NpdGlvbikpDQorICAgICAgIChtb3Zl LXRvLWNvbHVtbiBjb2wpKSkpDQoNCiAgICAod2hlbiAoYW5kIGxpbmUtbW92ZS1pZ25vcmUt aW52aXNpYmxlDQogIAkgICAgIChub3QgKGJvbHApKSAoaW52aXNpYmxlLXAgKDEtIChwb2lu dCkpKSkNCg== --------------020602020800010902020809 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --------------020602020800010902020809--