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#17244: 24.3.90; `line-move-visual' errors when moving across wrapped lines with an overlay property of 'display Date: Mon, 14 Apr 2014 11:11:34 +0300 Message-ID: <83fvlgl495.fsf@gnu.org> References: <834n1yu6lz.fsf@gnu.org> <0B5D9042-8250-4B40-9445-CEC864CFF458@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1397463148 11393 80.91.229.3 (14 Apr 2014 08:12:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2014 08:12:28 +0000 (UTC) Cc: 17244@debbugs.gnu.org To: Ivan Andrus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 14 10:12:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WZc00-0006tE-Ny for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Apr 2014 10:12:16 +0200 Original-Received: from localhost ([::1]:41363 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZc00-0000ld-82 for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Apr 2014 04:12:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZbzr-0000lY-VR for bug-gnu-emacs@gnu.org; Mon, 14 Apr 2014 04:12:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WZbzm-0006Wp-JY for bug-gnu-emacs@gnu.org; Mon, 14 Apr 2014 04:12:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZbzm-0006Wk-G3 for bug-gnu-emacs@gnu.org; Mon, 14 Apr 2014 04:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WZbzl-0002MO-Sy for bug-gnu-emacs@gnu.org; Mon, 14 Apr 2014 04:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Apr 2014 08:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17244 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17244-submit@debbugs.gnu.org id=B17244.13974631039039 (code B ref 17244); Mon, 14 Apr 2014 08:12:01 +0000 Original-Received: (at 17244) by debbugs.gnu.org; 14 Apr 2014 08:11:43 +0000 Original-Received: from localhost ([127.0.0.1]:47751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WZbzS-0002Li-MW for submit@debbugs.gnu.org; Mon, 14 Apr 2014 04:11:43 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:39060) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WZbzN-0002LD-1E for 17244@debbugs.gnu.org; Mon, 14 Apr 2014 04:11:38 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N4000H00GQE2D00@mtaout27.012.net.il> for 17244@debbugs.gnu.org; Mon, 14 Apr 2014 11:08:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N4000DK3H9NOH60@mtaout27.012.net.il>; Mon, 14 Apr 2014 11:08:11 +0300 (IDT) In-reply-to: <0B5D9042-8250-4B40-9445-CEC864CFF458@gmail.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:88012 Archived-At: > From: Ivan Andrus > Date: Sun, 13 Apr 2014 19:43:08 -0600 > Cc: 17244-done@debbugs.gnu.org > > > > > To tell the truth, Lisp code which covers large portions of buffer > > text with much shorter display strings that include newlines deserves > > to be broken. The current Emacs display engine was never designed to > > handle situations where the displayed text is so starkly different > > from buffer text, so the result of trying to fix "bugs" such as this > > one is a never-ending series of band-aids, one upon the other, which > > make the code utterly incomprehensible and unmaintainable. > > > > So I'm this close to refusing to fix such "bugs", and instead asking > > the authors of such Lisp to either find more benign ways of expressing > > what they need, or work around the limitations of the display engine > > in their own Lisp. > > > > So is the problem having newlines in the 'display property, or hiding large portions of the buffer? Each one of these is a problem. When they are present together in the same display string, the problems grow exponentially. > Because, in my original use case (my modified version of http://www.emacswiki.org/emacs/fold.el) I don’t think I have newlines in the display property, though I definitely hide large portions of the buffer. This is enough to cause problems. Consider what Emacs needs to do when you invoke "C-u N C-p" or "(line-move-visual -N)". It needs to find out what is the buffer position N screen lines before point. But where in the buffer is that? When those N lines display what is mostly buffer text, we can go back the appropriate amount of physical lines, and then start looking from there. But if what's on display in those N lines has little if any resemblance to what's in the buffer, the only safe algorithm is to go to the beginning of the buffer and start from there, which is prohibitively expensive. So Emacs implements several optimizations to make the operations reasonably fast. These optimizations only succeed when the display strings and the text they cover are approximately similar in length, or if the display strings are very short. The specific optimization that caused this bug was an attempt to be faster when text lines in a buffer are very long. > The overlays are also nested, so it might it be related to that? In what way are they nested? The problems happen only with overlays that have the 'display' property. > That said, your change seems to have fixed it. Thanks for testing. I must ask, though: why do you need to use display strings (rather than, say, invisible property) to do folding?