From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Alp Aker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 00:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8627@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13046400774617 (code B ref -1); Fri, 06 May 2011 00:02:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 May 2011 00:01:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI8Ts-0001CQ-SQ for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:17 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI8Tr-0001CB-8N for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI8Tl-0000OD-Co for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI8Tl-0000O9-BC for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:09 -0400 Received: from eggs.gnu.org ([140.186.70.92]:49726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI8Tk-0005OQ-AV for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI8Tj-0000Nw-6P for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:08 -0400 Received: from exprod7og109.obsmtp.com ([64.18.2.171]:32997) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QI8Ti-0000Np-Ts for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:07 -0400 Received: from mb1i1.ns.pitt.edu ([136.142.11.152]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTcM6PxCjivk6wDsYcRSTf25FQqD0fjFX@postini.com; Thu, 05 May 2011 17:01:06 PDT Received: from unixs1.cis.pitt.edu ([136.142.4.246]) by pitt.edu (PMDF V6.3-x11 #31505) with ESMTP id <0LKQ00K49YPRJE@mb1i1.ns.pitt.edu> for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:03 -0400 (EDT) Date: Thu, 05 May 2011 20:01:00 -0400 (EDT) From: Alp Aker X-X-Sender: aker@unixs1.cis.pitt.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) The documentation for the cursor property (info node "(elisp) Special Properties") states that: "Normally, the cursor is displayed at the end of any overlay and text property strings present at the current buffer position. You can place the cursor on any desired character of these strings by giving that character a non-`nil' `cursor' text property." And then follows the description of using integer values for the cursor property to make it applicable to a range of buffer positions other than the range between the overlay's start and end. However, when used with overlay before-strings (or after-strings), the cursor property appears to behave in ways that aren't consonant with the docs and that don't follow a consistent pattern. Here's a recipe for producing the variety of observed behaviors. (I use before-strings, but using after-strings gives similar results.) (1) Insert some boilerplate text to interact with. (save-excursion (goto-char (point-min)) (insert "Lorem ipsum dolor sit amet.\n")) Make an overlay and give it a before-string with a non-nil cursor property on one character: (setq olay (make-overlay 5 6) str1 (concat "XX" (propertize "Y" 'cursor t) "ZZ")) (overlay-put olay 'before-string str1) If one now does: (goto-char (overlay-start olay)) the cursor property is ignored; the cursor appears after the before-string. However, if the before-string appears before a newline, the cursor property is respected: (save-excursion (goto-char (point-min)) (search-forward "\n") (move-overlay olay (1- (point)) (point))) (goto-char (overlay-start olay)) The cursor now appears at the propertized character in the before-string. (2) Now give the overlay a before-string one of whose characters has a numeric cursor property: (setq str2 (concat "XX" (propertize "Y" 'cursor 1) "ZZ")) (overlay-put olay 'before-string str2) In this case, the property is respected regardless of location. With the overlay still at the newline: (goto-char (overlay-start olay)) and in the middle of a row: (move-overlay olay 5 6) (goto-char (overlay-start olay)) the cursor appears at the propertized character in the before-string. (3) But if the before-string contains a newline, the cursor property appears to be ignored regardless of location and regardless of whether the value of the cursor property is numeric or merely non-nil. With the overlay still in the middle of the line: (setq str3 (concat str1 "\nWWW") str4 (concat str2 "\nWWW")) (overlay-put olay 'before-string str3) (goto-char (overlay-start olay)) (overlay-put olay 'before-string str4) (goto-char (overlay-start olay)) the cursor appears after the before string, for both types of property value. Now moving the overlay back to the newline: (save-excursion (goto-char (point-min)) (search-forward "\n") (move-overlay olay (1- (point)) (point))) (goto-char (overlay-start olay)) (overlay-put olay 'before-string str3) (goto-char (overlay-start olay)) the cursor property is again ignored, in both cases. I started to read through xdisp.c to make some sense of this, but I'm too new to Emacs's internals to be able to follow much of the display routine. I did observe, though, that cursor_row_p only checks display properties, and doesn't appear to check before-strings and after-strings. In any case, it would appear that either the treatment of before-strings and after-strings should be changed so that the cursor property works with them as it does with strings that come from display properties, or the documentation should be amended to make clear that that it can't be expected to do so. (In the latter case, it would still seem desirable that cursor properties in before- and after-strings behave systematically, which isn't currently the case.) From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 11:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alp Aker Cc: 8627@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.130467982330671 (code B ref 8627); Fri, 06 May 2011 11:04:02 +0000 Received: (at 8627) by debbugs.gnu.org; 6 May 2011 11:03:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIIow-0007ye-Nb for submit@debbugs.gnu.org; Fri, 06 May 2011 07:03:42 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIIou-0007yR-AT for 8627@debbugs.gnu.org; Fri, 06 May 2011 07:03:41 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LKR00L00T7VYM00@a-mtaout22.012.net.il> for 8627@debbugs.gnu.org; Fri, 06 May 2011 14:03:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKR00JV0TDWT5N0@a-mtaout22.012.net.il>; Fri, 06 May 2011 14:03:34 +0300 (IDT) Date: Fri, 06 May 2011 14:03:34 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <831v0cm6pl.fsf@gnu.org> References: X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Thu, 05 May 2011 20:01:00 -0400 (EDT) > From: Alp Aker > > The documentation for the cursor property (info node "(elisp) Special > Properties") states that: > > "Normally, the cursor is displayed at the end of any overlay and text > property strings present at the current buffer position. You can place > the cursor on any desired character of these strings by giving that > character a non-`nil' `cursor' text property." > > And then follows the description of using integer values for the cursor > property to make it applicable to a range of buffer positions other than > the range between the overlay's start and end. Note that, crucially, the before-string and after-string properties are not described in this section. They are described elsewhere, where the `cursor' property is not mentioned. So I wonder if the `cursor' property was really supposed to work with before-strings and after-strings... > However, when used with overlay before-strings (or after-strings), the > cursor property appears to behave in ways that aren't consonant with the > docs and that don't follow a consistent pattern. It looks like it was never supported consistently, ever since the `cursor' property was introduced (in Emacs 22.1). > (1) Insert some boilerplate text to interact with. > > (save-excursion > (goto-char (point-min)) > (insert "Lorem ipsum dolor sit amet.\n")) > > Make an overlay and give it a before-string with a non-nil cursor property > on one character: > > (setq olay (make-overlay 5 6) > str1 (concat "XX" > (propertize "Y" 'cursor t) > "ZZ")) > (overlay-put olay 'before-string str1) > > If one now does: > > (goto-char (overlay-start olay)) > > the cursor property is ignored; the cursor appears after the > before-string. This works as expected in Emacs 23, so it must be some problem with the bidi-aware redisplay in Emacs 24. I will take a look when I have time; thanks for a clear test case. > (3) But if the before-string contains a newline, the cursor property > appears to be ignored regardless of location and regardless of whether the > value of the cursor property is numeric or merely non-nil. This never worked, I tested it in Emacs 22.1, and it behaves like this as well. I will take a look at fixing this, bat can you show a real-life use case where this is needed? > I started to read through xdisp.c to make some sense of this, but I'm too > new to Emacs's internals to be able to follow much of the display routine. > I did observe, though, that cursor_row_p only checks display properties, > and doesn't appear to check before-strings and after-strings. It may come as a surprise, but the implementation of display properties is very different from that of before-string and after-string properties. It's a small wonder they don't behave similarly. > In any case, it would appear that either the treatment of before-strings > and after-strings should be changed so that the cursor property works with > them as it does with strings that come from display properties, or the > documentation should be amended to make clear that that it can't be > expected to do so. (In the latter case, it would still seem desirable > that cursor properties in before- and after-strings behave systematically, > which isn't currently the case.) It sounds like it works in most use cases, so fixing the implementation is probably a better alternative. From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 8627@debbugs.gnu.org, Alp Aker Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.130469002315949 (code B ref 8627); Fri, 06 May 2011 13:54:02 +0000 Received: (at 8627) by debbugs.gnu.org; 6 May 2011 13:53:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QILTR-00049A-Al for submit@debbugs.gnu.org; Fri, 06 May 2011 09:53:43 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QILTQ-00048y-1A for 8627@debbugs.gnu.org; Fri, 06 May 2011 09:53:40 -0400 Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:41001 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QILTJ-0006ty-7y; Fri, 06 May 2011 09:53:33 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 9A66F66168; Fri, 6 May 2011 10:53:30 -0300 (ART) From: Stefan Monnier Message-ID: References: <831v0cm6pl.fsf@gnu.org> Date: Fri, 06 May 2011 10:53:30 -0300 In-Reply-To: <831v0cm6pl.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 May 2011 14:03:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) > Note that, crucially, the before-string and after-string properties > are not described in this section. They are described elsewhere, > where the `cursor' property is not mentioned. So I wonder if the > `cursor' property was really supposed to work with before-strings and > after-strings... The only use of `cursor' of which I remember is in minibuffer-message, on an after-string. It's used when we display " [Sole completion]" and such messages. So, yes, it's supposed to work on before/after-strings ;-) Stefan From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Alp Aker Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 May 2011 21:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 8627@debbugs.gnu.org, Eli Zaretskii Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.130471664624198 (code B ref 8627); Fri, 06 May 2011 21:18:02 +0000 Received: (at 8627) by debbugs.gnu.org; 6 May 2011 21:17:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QISOr-0006IF-NZ for submit@debbugs.gnu.org; Fri, 06 May 2011 17:17:25 -0400 Received: from exprod7og115.obsmtp.com ([64.18.2.217]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QISOp-0006I2-Io for 8627@debbugs.gnu.org; Fri, 06 May 2011 17:17:24 -0400 Received: from mb2i1.ns.pitt.edu ([136.142.11.153]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTcRlXQAxlcxpZ3Z7JwFrRoh0VxE6Mo8X@postini.com; Fri, 06 May 2011 14:17:23 PDT Received: from unixs1.cis.pitt.edu ([136.142.4.246]) by pitt.edu (PMDF V6.3-x11 #31505) with ESMTP id <0LKS00LC8LSSNE@mb2i1.ns.pitt.edu> for 8627@debbugs.gnu.org; Fri, 06 May 2011 17:17:16 -0400 (EDT) Date: Fri, 06 May 2011 17:17:16 -0400 (EDT) From: Alp Aker In-reply-to: X-X-Sender: aker@unixs1.cis.pitt.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII References: <831v0cm6pl.fsf@gnu.org> X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) >> But if the before-string contains a newline, the cursor property >> appears to be ignored. > > I will take a look at fixing this, but can you show a real-life use > case where this is needed? I ran into the need while working on this package: emacswiki.org/emacs/FillColumnIndicator It shades the area past the fill column by putting overlays on newlines (if you look at the screenshot it'll be obvious how it works). In a few edge cases it would be useful to be able to display a newline that's not part of the buffer content. For example, if the last line of the buffer doesn't end in a newline, then no fill-column shading appears on that line (since there's no newline to propertize). I'd like to put an overlay at point-max with an after-string containing a propertized newline character, so that the fill-column shading can appear on the last line of the buffer. But I can't do so, because the newline in the after-string causes any cursor property in it to be ignored, and so cursor motion at the end of the buffer becomes deranged. (Display strings won't do here, because I don't want to replace the display of any characters in the buffer.) Does that qualify as a use case? I might as well also mention, at least for the record, another (minor) issue with cursor properties in before-strings that I came across: If the position with the cursor property is out of sight because of horizontal scrolling, then the property is ignored, even when auto-hscroll-mode is enabled. Perhaps it would make more sense to respect the cursor property when auto-hscroll-mode is non-nil, and adjust hscrolling to bring the requested cursor position into view? Here's a test case: (progn (setq auto-hscroll-mode t) ;; A line of text, moving to the end of which will trigger hscrolling. (insert (make-string (+ hscroll-margin (window-width) 5) ?X)) (setq m (point-marker)) (insert "\n\n") (setq o (make-overlay (1- (point)) (point))) ;; Request that cursor be at bol, but make the before-string long ;; enough that if the cursor property is ignored we won't return from ;; hscrolling. (overlay-put o 'before-string (concat (propertize " " 'cursor 1) (make-string (window-width) 32))) (goto-char m) (redisplay) (forward-line 1)) After evaluation the cursor will be at the end of the before-string, rather than at the requested position. (This happens with 22 and 23 as well.) From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 May 2011 07:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alp Aker Cc: 8627@debbugs.gnu.org, monnier@iro.umontreal.ca Reply-To: Eli Zaretskii Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.130475320013898 (code B ref 8627); Sat, 07 May 2011 07:27:01 +0000 Received: (at 8627) by debbugs.gnu.org; 7 May 2011 07:26:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIbuO-0003c3-61 for submit@debbugs.gnu.org; Sat, 07 May 2011 03:26:40 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QIbuL-0003bn-KH for 8627@debbugs.gnu.org; Sat, 07 May 2011 03:26:34 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LKT00H00DQ4HB00@a-mtaout23.012.net.il> for 8627@debbugs.gnu.org; Sat, 07 May 2011 10:26:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.234.175]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LKT00HLUE01FH50@a-mtaout23.012.net.il>; Sat, 07 May 2011 10:26:26 +0300 (IDT) Date: Sat, 07 May 2011 10:26:28 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83d3jvkm3f.fsf@gnu.org> References: <831v0cm6pl.fsf@gnu.org> X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) > Date: Fri, 06 May 2011 17:17:16 -0400 (EDT) > From: Alp Aker > Cc: Eli Zaretskii , 8627@debbugs.gnu.org > > Does that qualify as a use case? Yes, of course. Thanks for the other info. I will take a look. From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 May 2011 20:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alp Aker Cc: 8627@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.13067025059587 (code B ref 8627); Sun, 29 May 2011 20:56:02 +0000 Received: (at 8627) by debbugs.gnu.org; 29 May 2011 20:55:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QQn0q-0002Ua-Qa for submit@debbugs.gnu.org; Sun, 29 May 2011 16:55:05 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QQn0o-0002U5-F8 for 8627@debbugs.gnu.org; Sun, 29 May 2011 16:55:03 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LLZ001005VQYP00@a-mtaout22.012.net.il> for 8627@debbugs.gnu.org; Sun, 29 May 2011 23:54:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.255.155]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LLZ00NDR63233R0@a-mtaout22.012.net.il>; Sun, 29 May 2011 23:54:39 +0300 (IDT) Date: Sun, 29 May 2011 23:54:45 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8362otgrca.fsf@gnu.org> References: X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Thu, 05 May 2011 20:01:00 -0400 (EDT) > From: Alp Aker > > However, when used with overlay before-strings (or after-strings), the > cursor property appears to behave in ways that aren't consonant with the > docs and that don't follow a consistent pattern. I took a quick look at this bug. I must say I wish this feature were never introduced into Emacs: it is hackyish, its implementation is kludgey, and supporting it in the bidirectional display engine will be a PITA. It also makes no sense at all in some use cases. E.g., if you put a `cursor' property with an integer value of 1 on either a before-string or an after-string, the cursor will never be positioned on the character at point, although it is clearly visible. And if the value is greater than 1, the cursor will appear to be "stuck" for that many C-f keypresses. I'm sure some users will think it's a bug. Anyway, I will eventually fix the code to do what it did in Emacs 23, with one exception: > (3) But if the before-string contains a newline, the cursor property > appears to be ignored regardless of location and regardless of whether the > value of the cursor property is numeric or merely non-nil. With the > overlay still in the middle of the line: > > (setq str3 (concat str1 "\nWWW") > str4 (concat str2 "\nWWW")) > (overlay-put olay 'before-string str3) > (goto-char (overlay-start olay)) > (overlay-put olay 'before-string str4) > (goto-char (overlay-start olay)) > > the cursor appears after the before string, for both types of property > value. This cannot possibly work, not without rewriting the Emacs display engine in ways I don't intend to. Quite simply, you cannot put the `cursor' property on a newline that belongs to a string, because a newline, obviously, doesn't have a graphic representation (a glyph) on the screen, it just causes Emacs to continue drawing on the next screen line. The function that decides where to position the cursor scans the glyphs on the line that contains point, looking for a glyph that came from some string position that has a non-nil `cursor' property. If it finds such a glyph, it then does what you expect. But it will never find a glyph that corresponds to a newline, and so the `cursor' property on a newline that comes from a before- or after-string will never be noticed. It is effectively lost in the data structure (called a `glyph matrix') which Emacs uses to draw and redraw the screen. In fact, with a newline from a string, Emacs doesn't even consider the screen line where you wanted it to put the cursor be a candidate for drawing the cursor, because the newline moves the buffer position "covered" by the overlay to the next screen line. I will eventually update the documentation with this caveat. It's too bad that this is exactly the feature that you needed, but you will have to rethink how to get the same effect. I suggest putting the overlay on some different character in the string, and giving the `cursor' property a value > 1, maybe that will do what you want (although I admit that I don't quite understand your exact situation). > In any case, it would appear that either the treatment of before-strings > and after-strings should be changed so that the cursor property works with > them as it does with strings that come from display properties That's not possible, because there's a fundamental difference between the `display' properties whose values are strings and before- and after-string properties: the former are _replacing_ properties, i.e. these strings are displayed _instead_ of the buffer text covered by the property/overlay. By contrast, before- and after-strings do not replace the text that is covered by the overlay. The code that treats these two use cases is thus different in pretty much fundamental ways. From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Dec 2021 20:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 8627@debbugs.gnu.org, Alp Aker Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.163864937526325 (code B ref 8627); Sat, 04 Dec 2021 20:23:02 +0000 Received: (at 8627) by debbugs.gnu.org; 4 Dec 2021 20:22:55 +0000 Received: from localhost ([127.0.0.1]:55118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbYc-0006qW-QL for submit@debbugs.gnu.org; Sat, 04 Dec 2021 15:22:54 -0500 Received: from quimby.gnus.org ([95.216.78.240]:40814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbYb-0006qG-1X for 8627@debbugs.gnu.org; Sat, 04 Dec 2021 15:22:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TcyXz65Hx5Dp4vIu/9p8C5p5+CUWG7c9Taq82mjZEhA=; b=TeqC4eWzErbidHmwXiSpZsNN4b D09xIX9XlHznX/k+fbP3NY0zyiNffYzZyGN4yM6tTIV/eEbFTLyZ2tozVlucA/zj9M2gzTR/Iycga coisKg8jrjV42I0jtFJf3esFpNhXGUt/g85jszEFrngKpuyvp1wqvX5vpuEEBXShgztw=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtbYS-0000Aa-HC; Sat, 04 Dec 2021 21:22:47 +0100 From: Lars Ingebrigtsen References: <8362otgrca.fsf@gnu.org> X-Now-Playing: Kraftwerk's _Exceller 8_: "Klingklang" Date: Sat, 04 Dec 2021 21:22:44 +0100 In-Reply-To: <8362otgrca.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 29 May 2011 23:54:45 +0300") Message-ID: <875ys43ysr.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > This cannot possibly work, not without rewriting the Emacs display > engine in ways I don't intend to. Quite simply, you cannot put the > `cursor' property on a newline that belongs to a string, bec [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > This cannot possibly work, not without rewriting the Emacs display > engine in ways I don't intend to. Quite simply, you cannot put the > `cursor' property on a newline that belongs to a string, because a > newline, obviously, doesn't have a graphic representation (a glyph) on > the screen, it just causes Emacs to continue drawing on the next > screen line. [...] > I will eventually update the documentation with this caveat. This was ten years ago -- I didn't check whether the documentation has been updated, but there doesn't seem to be anything more to do here than that? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 04 15:22:58 2021 Received: (at control) by debbugs.gnu.org; 4 Dec 2021 20:22:58 +0000 Received: from localhost ([127.0.0.1]:55121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbYg-0006ql-23 for submit@debbugs.gnu.org; Sat, 04 Dec 2021 15:22:58 -0500 Received: from quimby.gnus.org ([95.216.78.240]:40830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbYe-0006qL-H2 for control@debbugs.gnu.org; Sat, 04 Dec 2021 15:22:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=z7MNvJqA/PSYBPIRyrNaISYXCeD9SPqMmsRmp6VjjKM=; b=kaXTe3Tvhtd78IajZprO4rRoj6 L1H0kkcrkseYzk5KkgaeBHFZxpG4G/rjrHxDPJJyngYIqE0nBya4puJN7UmV9LVxU5mdeq8TI3ldg NrNVhjkyepXzY2W9qbF0Ri7tLFxI8I4uahZ805zXDMlSIqrkQMSmNRMEYw09UHGPQtoA=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtbYX-0000Ah-1T for control@debbugs.gnu.org; Sat, 04 Dec 2021 21:22:51 +0100 Date: Sat, 04 Dec 2021 21:22:48 +0100 Message-Id: <874k7o3ysn.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #8627 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 8627 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 8627 + moreinfo quit From unknown Sat Aug 16 18:44:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Dec 2021 20:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Lars Ingebrigtsen Cc: 8627@debbugs.gnu.org, aker@pitt.edu Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.16386507075044 (code B ref 8627); Sat, 04 Dec 2021 20:46:01 +0000 Received: (at 8627) by debbugs.gnu.org; 4 Dec 2021 20:45:07 +0000 Received: from localhost ([127.0.0.1]:55178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbu7-0001Iq-1H for submit@debbugs.gnu.org; Sat, 04 Dec 2021 15:45:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtbu5-0001Cb-5p for 8627@debbugs.gnu.org; Sat, 04 Dec 2021 15:45:05 -0500 Received: from [2001:470:142:3::e] (port=45166 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtbtw-0000sV-Dd; Sat, 04 Dec 2021 15:44:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RJB6c1pfy43zZwoXGtwd9R9NXgwy7Y4rs+gImMjFnNg=; b=hfVarOPahiL4 g58eEPz5TQSOsx+s/beptZnOABVDfiNC1DvesxtSxGFEH4NRZDeBrUbGzhX2afxXH6n8aMEBV9u3x xphU4jDhtYshWi+cxgMIeeje9KxN6O+gDXKLoNZCmSahMq8lyy59N/orhMFRQLGcjLdBlE9qxU46Z G4rye2erz1enDvOpHECN3FDw5EkYw7GuaPKA4XRjbMrsnnzP+pr+nKx00Y0sE1rKtOxDqA0g4EU5S SVcTqZeti4hV+5KhJzLoUlBTK7J/Ur1SHRnH73VZL7osiIyhcJWQH/yAIpKzFn+xHWhKLWiXQX+M9 sRxaqJBTqhkuJml2p1To6Q==; Received: from [87.69.77.57] (port=4025 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtbtw-0004c1-6u; Sat, 04 Dec 2021 15:44:56 -0500 Date: Sat, 04 Dec 2021 22:44:50 +0200 Message-Id: <835ys45ccd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875ys43ysr.fsf_-_@gnus.org> (message from Lars Ingebrigtsen on Sat, 04 Dec 2021 21:22:44 +0100) References: <8362otgrca.fsf@gnu.org> <875ys43ysr.fsf_-_@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Alp Aker , 8627@debbugs.gnu.org > Date: Sat, 04 Dec 2021 21:22:44 +0100 > > Eli Zaretskii writes: > > > This cannot possibly work, not without rewriting the Emacs display > > engine in ways I don't intend to. Quite simply, you cannot put the > > `cursor' property on a newline that belongs to a string, because a > > newline, obviously, doesn't have a graphic representation (a glyph) on > > the screen, it just causes Emacs to continue drawing on the next > > screen line. > > [...] > > > I will eventually update the documentation with this caveat. > > This was ten years ago -- I didn't check whether the documentation has > been updated, but there doesn't seem to be anything more to do here than > that? I promised to fix at least some of the behavior, but never did. I will take a look soon. From unknown Sat Aug 16 18:44:43 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alp Aker Subject: bug#8627: closed (Re: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings) Message-ID: References: <83sfv72jvj.fsf@gnu.org> X-Gnu-PR-Message: they-closed 8627 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: moreinfo Reply-To: 8627@debbugs.gnu.org Date: Sun, 05 Dec 2021 18:09:14 +0000 Content-Type: multipart/mixed; boundary="----------=_1638727754-2342-1" This is a multi-part message in MIME format... ------------=_1638727754-2342-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #8627: 24.0.50: cursor property behaves irregularly in before-strings which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 8627@debbugs.gnu.org. --=20 8627: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8627 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1638727754-2342-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 8627-done) by debbugs.gnu.org; 5 Dec 2021 18:08:14 +0000 Received: from localhost ([127.0.0.1]:59278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtvvo-0000UR-6t for submit@debbugs.gnu.org; Sun, 05 Dec 2021 13:08:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtsjF-0006oG-3z for 8627-done@debbugs.gnu.org; Sun, 05 Dec 2021 09:43:02 -0500 Received: from [2001:470:142:3::e] (port=40444 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtsiz-0003Q0-Go; Sun, 05 Dec 2021 09:42:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/MVSze2NMtsPF/M1rbvE53KacQgVpN/ByWgUqGPPIsg=; b=Jc0jUoucqAFg aWSKf1JynGn/TuYUY778taykCs3kLuZu9KNHXu0ens/tyHagctmDUmN9USrhQef7r9tA0GKTqHv9v Hmw/CLEy8ZgowdzOp7Rb3vTKQPUsx1mrP+DR1wgIH3/dOTjSjRl2PklSThZaR4323BSoiUgAuIom6 QPSPUzIGgnEx9cXwmcwoamYDrrm116IlIaRc/m+pgmduRBXzVNigU0PjCaIZt/M9aG7fBpEfPXZNR Pev24R2phNIQ0VvWxUO6gSWJ8ldHTxL/+92PZ33nvMIUs+qQh4kTSeO6ajxw+wy11z27jkWxhvaqG cV5iwmlzUidbcMpcXD0Zvw==; Received: from [87.69.77.57] (port=2897 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtsiy-0006zT-Oo; Sun, 05 Dec 2021 09:42:45 -0500 Date: Sun, 05 Dec 2021 16:42:40 +0200 Message-Id: <83sfv72jvj.fsf@gnu.org> From: Eli Zaretskii To: larsi@gnus.org In-Reply-To: <835ys45ccd.fsf@gnu.org> (message from Eli Zaretskii on Sat, 04 Dec 2021 22:44:50 +0200) Subject: Re: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings References: <8362otgrca.fsf@gnu.org> <875ys43ysr.fsf_-_@gnus.org> <835ys45ccd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 8627-done Cc: 8627-done@debbugs.gnu.org, aker@pitt.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 04 Dec 2021 22:44:50 +0200 > From: Eli Zaretskii > Cc: 8627@debbugs.gnu.org, aker@pitt.edu > > > From: Lars Ingebrigtsen > > Cc: Alp Aker , 8627@debbugs.gnu.org > > Date: Sat, 04 Dec 2021 21:22:44 +0100 > > > > Eli Zaretskii writes: > > > > > This cannot possibly work, not without rewriting the Emacs display > > > engine in ways I don't intend to. Quite simply, you cannot put the > > > `cursor' property on a newline that belongs to a string, because a > > > newline, obviously, doesn't have a graphic representation (a glyph) on > > > the screen, it just causes Emacs to continue drawing on the next > > > screen line. > > > > [...] > > > > > I will eventually update the documentation with this caveat. > > > > This was ten years ago -- I didn't check whether the documentation has > > been updated, but there doesn't seem to be anything more to do here than > > that? > > I promised to fix at least some of the behavior, but never did. I > will take a look soon. I took a look. The code works correctly: since the before-string leaves the buffer position visible, Emacs by default places the cursor there, and a non-nil value of the 'cursor' property cannot override this basic behavior. If Emacs 23 behaved differently, it was a bug in Emacs 23. By contrast, when the value of 'cursor' is an integer, then the cursor is placed on that character even if the corresponding buffer position is visible. Which is what Emacs now does. So I've now documented these caveats, including the one wrt newline characters, and I'm finally marking this bug done. ------------=_1638727754-2342-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 6 May 2011 00:01:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI8Ts-0001CQ-SQ for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:17 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QI8Tr-0001CB-8N for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI8Tl-0000OD-Co for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI8Tl-0000O9-BC for submit@debbugs.gnu.org; Thu, 05 May 2011 20:01:09 -0400 Received: from eggs.gnu.org ([140.186.70.92]:49726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI8Tk-0005OQ-AV for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI8Tj-0000Nw-6P for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:08 -0400 Received: from exprod7og109.obsmtp.com ([64.18.2.171]:32997) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QI8Ti-0000Np-Ts for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:07 -0400 Received: from mb1i1.ns.pitt.edu ([136.142.11.152]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTcM6PxCjivk6wDsYcRSTf25FQqD0fjFX@postini.com; Thu, 05 May 2011 17:01:06 PDT Received: from unixs1.cis.pitt.edu ([136.142.4.246]) by pitt.edu (PMDF V6.3-x11 #31505) with ESMTP id <0LKQ00K49YPRJE@mb1i1.ns.pitt.edu> for bug-gnu-emacs@gnu.org; Thu, 05 May 2011 20:01:03 -0400 (EDT) Date: Thu, 05 May 2011 20:01:00 -0400 (EDT) From: Alp Aker Subject: 24.0.50: cursor property behaves irregularly in before-strings X-X-Sender: aker@unixs1.cis.pitt.edu To: bug-gnu-emacs@gnu.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) The documentation for the cursor property (info node "(elisp) Special Properties") states that: "Normally, the cursor is displayed at the end of any overlay and text property strings present at the current buffer position. You can place the cursor on any desired character of these strings by giving that character a non-`nil' `cursor' text property." And then follows the description of using integer values for the cursor property to make it applicable to a range of buffer positions other than the range between the overlay's start and end. However, when used with overlay before-strings (or after-strings), the cursor property appears to behave in ways that aren't consonant with the docs and that don't follow a consistent pattern. Here's a recipe for producing the variety of observed behaviors. (I use before-strings, but using after-strings gives similar results.) (1) Insert some boilerplate text to interact with. (save-excursion (goto-char (point-min)) (insert "Lorem ipsum dolor sit amet.\n")) Make an overlay and give it a before-string with a non-nil cursor property on one character: (setq olay (make-overlay 5 6) str1 (concat "XX" (propertize "Y" 'cursor t) "ZZ")) (overlay-put olay 'before-string str1) If one now does: (goto-char (overlay-start olay)) the cursor property is ignored; the cursor appears after the before-string. However, if the before-string appears before a newline, the cursor property is respected: (save-excursion (goto-char (point-min)) (search-forward "\n") (move-overlay olay (1- (point)) (point))) (goto-char (overlay-start olay)) The cursor now appears at the propertized character in the before-string. (2) Now give the overlay a before-string one of whose characters has a numeric cursor property: (setq str2 (concat "XX" (propertize "Y" 'cursor 1) "ZZ")) (overlay-put olay 'before-string str2) In this case, the property is respected regardless of location. With the overlay still at the newline: (goto-char (overlay-start olay)) and in the middle of a row: (move-overlay olay 5 6) (goto-char (overlay-start olay)) the cursor appears at the propertized character in the before-string. (3) But if the before-string contains a newline, the cursor property appears to be ignored regardless of location and regardless of whether the value of the cursor property is numeric or merely non-nil. With the overlay still in the middle of the line: (setq str3 (concat str1 "\nWWW") str4 (concat str2 "\nWWW")) (overlay-put olay 'before-string str3) (goto-char (overlay-start olay)) (overlay-put olay 'before-string str4) (goto-char (overlay-start olay)) the cursor appears after the before string, for both types of property value. Now moving the overlay back to the newline: (save-excursion (goto-char (point-min)) (search-forward "\n") (move-overlay olay (1- (point)) (point))) (goto-char (overlay-start olay)) (overlay-put olay 'before-string str3) (goto-char (overlay-start olay)) the cursor property is again ignored, in both cases. I started to read through xdisp.c to make some sense of this, but I'm too new to Emacs's internals to be able to follow much of the display routine. I did observe, though, that cursor_row_p only checks display properties, and doesn't appear to check before-strings and after-strings. In any case, it would appear that either the treatment of before-strings and after-strings should be changed so that the cursor property works with them as it does with strings that come from display properties, or the documentation should be amended to make clear that that it can't be expected to do so. (In the latter case, it would still seem desirable that cursor properties in before- and after-strings behave systematically, which isn't currently the case.) ------------=_1638727754-2342-1--