From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#8627: 24.0.50: cursor property behaves irregularly in before-strings Date: Sun, 29 May 2011 23:54:45 +0300 Message-ID: <8362otgrca.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1306702574 5593 80.91.229.12 (29 May 2011 20:56:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 May 2011 20:56:14 +0000 (UTC) Cc: 8627@debbugs.gnu.org To: Alp Aker Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 29 22:56:09 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QQn1t-0007zJ-8k for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 May 2011 22:56:09 +0200 Original-Received: from localhost ([::1]:35375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQn1s-0000XM-Qp for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 May 2011 16:56:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQn1p-0000XH-GW for bug-gnu-emacs@gnu.org; Sun, 29 May 2011 16:56:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QQn1m-0006WM-V2 for bug-gnu-emacs@gnu.org; Sun, 29 May 2011 16:56:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQn1m-0006WI-S3 for bug-gnu-emacs@gnu.org; Sun, 29 May 2011 16:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QQn1m-0002Vn-C0; Sun, 29 May 2011 16:56:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 8627-submit@debbugs.gnu.org id=B8627.13067025059587 (code B ref 8627); Sun, 29 May 2011 20:56:02 +0000 Original-Received: (at 8627) by debbugs.gnu.org; 29 May 2011 20:55:05 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 29 May 2011 16:56:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:46787 Archived-At: > 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.