From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Display problems with `before-string' in overlay Date: Sun, 15 Apr 2007 11:45:38 -0400 Message-ID: <87r6qltzdp.fsf@stupidchicken.com> References: <461C10A0.1010309@gmail.com> <87y7kyvm6a.fsf@stupidchicken.com> <461D49A2.5070803@gmail.com> <461DCB05.7090204@gmail.com> <87r6qof8ln.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1176652780 30025 80.91.229.12 (15 Apr 2007 15:59:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 15 Apr 2007 15:59:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 15 17:59:33 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 1Hd78T-00088J-IX for ged-emacs-devel@m.gmane.org; Sun, 15 Apr 2007 17:59:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hd7Cy-0007hZ-VY for ged-emacs-devel@m.gmane.org; Sun, 15 Apr 2007 12:04:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hd79P-000423-Kt for emacs-devel@gnu.org; Sun, 15 Apr 2007 12:00:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hd79P-00041r-66 for emacs-devel@gnu.org; Sun, 15 Apr 2007 12:00:27 -0400 Original-Received: from south-station-annex.mit.edu ([18.72.1.2]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hd74s-0002qW-Ue; Sun, 15 Apr 2007 11:55:47 -0400 Original-Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l3FFtiii014815; Sun, 15 Apr 2007 11:55:45 -0400 (EDT) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by central-city-carrier-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3FFjeO4005512; Sun, 15 Apr 2007 11:45:42 -0400 (EDT) Original-Received: from localhost (SYDNEYPACIFIC-SEVEN-FIFTY-SEVEN.MIT.EDU [18.95.7.246]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id l3FFjc4P002199; Sun, 15 Apr 2007 11:45:39 -0400 (EDT) Original-Received: from cyd by localhost with local (Exim 3.36 #1 (Debian)) id 1Hd6v4-0001ju-00; Sun, 15 Apr 2007 11:45:38 -0400 In-Reply-To: (Richard Stallman's message of "Sun\, 15 Apr 2007 09\:59\:21 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: -2.599 X-detected-kernel: Solaris 9.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:69458 Archived-At: Richard Stallman writes: > your change is to replace > > (beg < PT /* && end > PT <- It's always the case. */ > || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)) > > with a condition that is always true. Could you please explain the > motive for that change? Why is it correct to adjust point when it > starts out at the beginning of an overlay with a `display' property? Let me try to explain (again) what the problem is. It boils down to where to display the cursor when point is at the beginning/end of an overlay with a `display' property. Currently, the cursor can show up at the following positions (where OOO denotes the overlay, and ABC denotes the surrounding characters): A B|O O O C (point = 3) A B O O O|C (point = 6) The problem arises when you have multi-line overlays. In Emacs 21, redisplay used a simple rule (see cursor_row_p): "if PT is at the end of a row, and the row ends with a newline from a string, don't put cursor on that row." This rule is desirable for multi-line before-strings: A B X X X|O C A B X X X O|C But this rule is bad for multi-line display strings, because the cursor gets pushed down to the next line: A B O O |O C (point = 3) A B O O O|C (point = 6) The 2005-07-13 change by KFS revoked this rule. Now, that cursor can live on a row ending in a newline from a string. For multi-line display strings, we have A B|O O O C (point = 3) A B O O O|C (point = 6) Note that we MUST revoke the rule if we want multi-line display strings to behave similar to single-line display strings. So far so good. But revoking the rule screws up multi-line before-strings, because redisplay now tries to draw the cursor on the first line where the string occurs: A B X X| X C A B X X X C| The naive approach to solving this problem is to change the rule to "if a row ends with a newline from a before-string, don't put cursor on that row." Unfortunately, this is very difficult to implement, because the glyph matrix does not store information about whether a string came from a display string or some other source (this is a deliberate decision for reducing the size of the glyph structure). Various approaches to extract this information (such as using get_char_property) don't work for complicated reasons; if someone comes up with a fast workable solution for this, I'm all ears. The only other possibility I'm aware of is to sidestep the issue entirely, by changing adjust_point_for_property so that point can't land on the start of the overlay. For instance: A|B O O O C (point = 2) [point can't be at position 3] A B O O O|C (point = 6) A|B O O O C (point = 2) A B O O O|C (point = 6) The trouble with this is that the current adjust_point_for_property behavior has been in place for a very long time now, and some packages may have come to rely on it. So changing this code is not to be done lightly. Thus, the current situation is that the cursor is drawn in the wrong position for mutli-line before-strings. However, (1) this is a seldom-used feature; note that it took 2 years after KFS's change for someone to notice this (2) There are many redisplay options for working around this bug. (3) Even though the cursor position is drawn incorrectly, there is no corruption of point or buffer contents, so it's at most a glitch that people can live with. So unless you can come up with an explanation for why changing the code has no danger of causing instability, I think we should leave things as they currently are, and adopt my proposed fix for 22.2.