From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 12:56:11 +0200 Message-ID: References: <87a9p79gnv.fsf@gmail.com> <20130410095450.GA31506@kuru.dyndns-at-home.com> <83a9p69x0c.fsf@gnu.org> <262C4E11-6D4B-4033-A619-1702CC8D0F94@gmail.com> <86fvyycfa9.fsf@somewhere.org> <83vc7t9dr1.fsf@gnu.org> <8461B483-8CC4-4D37-94BD-5CBEED773ADE@gmail.com> <83ip3s9rp8.fsf@gnu.org> <5A8E6625-33C1-4B94-A78E-B08268C57A5F@gmail.com> <83fvyw9mkh.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:36075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQbeT-0000xT-Bd for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 06:56:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQbeP-00041J-FP for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 06:56:17 -0400 In-Reply-To: <83fvyw9mkh.fsf@gnu.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eli Zaretskii Cc: emacs-orgmode@gnu.org On 12 apr. 2013, at 10:31, Eli Zaretskii wrote: >> From: Carsten Dominik >> Date: Fri, 12 Apr 2013 09:13:47 +0200 >> Cc: emacs-orgmode@gnu.org >> >>> Just search xdisp.c for "overlay", you will see the story quite >>> clearly, I think. >> >> My Sunday pleasure reading project. > > Good luck, and let me know if you need something explained. The > commentary at the beginning of the file might serve as an > introduction, although it doesn't really touch the issue at hand. > >> So the reason that the combination with hi-line is slow is because >> hl-line is using post-command-hook to move its overlay, and redisplay >> of a full window with org-mode is slow because so much stuff is >> hidden and Emacs makes a full re-evaluation of what needs >> to be displayed? > > Right. If hi-line (or any similar mode) is off, then at least > horizontal cursor motion should be fast, because then Emacs knows that > nothing changed, and finding the place where to put the cursor on the > same line it was before is relatively easy. > > But even C-n and C-p is quite another story in an Org buffer: Emacs > needs to determine where that puts point, and doing so generally means > traversing all of the hidden parts of the buffer between the line > which was current and the new current line. In a complex Org buffer, > that could easily be many thousands of buffer positions. I guess outline mode does have the exact same problem in this case, in fact any mode with large amount of hidden text. > > Also, recall that, under line-move-visual, which is nowadays on by > default, Not in my setup, but since it the default, yes, this causes more issues. Another important point to be aware of. > Emacs moves by _screen_ lines, not by physical lines. So a > simple C-n must internally emulate display to find the next line > visible on the screen by traversing the buffer one character at a time > and taking note of each and every text property and overlay in > between, until it finds the buffer position whose screen coordinates > are [X,Y+N], where [X,Y] are the coordinates of the previous cursor > position and N is the line height in pixels. And this is just to find > where point will be; then the screen must actually be redisplayed, > which might mean more work, if the new position of point requires > scrolling, e.g. if cursor went off the scroll margins or whatever. > > We only get reasonably fast performance with all this complexity > because our machines are incredibly fast. But we are many times on > the edge, as the bug I cited and similar ones show. Thanks again. - Carsten