From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 11:31:58 +0300 Message-ID: <83fvyw9mkh.fsf@gnu.org> 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> Reply-To: Eli Zaretskii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:57375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQZPI-0004cs-8e for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 04:32:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQZPH-0002MU-1d for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 04:32:28 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQZPG-0002MK-PM for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 04:32:26 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0ML400C00VIACE00@a-mtaout21.012.net.il> for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 11:31:58 +0300 (IDT) In-reply-to: <5A8E6625-33C1-4B94-A78E-B08268C57A5F@gmail.com> 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: Carsten Dominik Cc: emacs-orgmode@gnu.org > 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. Also, recall that, under line-move-visual, which is nowadays on by default, 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.