From: Carsten Dominik <carsten.dominik@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Enriched/Org is a colorful Org
Date: Fri, 12 Apr 2013 12:56:11 +0200 [thread overview]
Message-ID: <FFA190FA-6F2E-4983-AD4E-7D0F60378AE4@gmail.com> (raw)
In-Reply-To: <83fvyw9mkh.fsf@gnu.org>
On 12 apr. 2013, at 10:31, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Carsten Dominik <carsten.dominik@gmail.com>
>> 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
next prev parent reply other threads:[~2013-04-12 10:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 4:02 Enriched/Org is a colorful Org Jambunathan K
2013-04-10 9:54 ` Suvayu Ali
2013-04-10 10:16 ` Carsten Dominik
2013-04-10 10:39 ` Torsten Wagner
2013-04-10 10:48 ` Suvayu Ali
2013-04-10 10:53 ` Carsten Dominik
2013-04-10 11:20 ` Sebastien Vauban
2013-04-10 11:26 ` Carsten Dominik
2013-04-10 12:15 ` Jambunathan K
2013-04-10 11:57 ` Jambunathan K
2013-04-10 16:21 ` Eli Zaretskii
2013-04-10 16:43 ` Jambunathan K
2013-04-10 17:13 ` Eli Zaretskii
2013-04-10 19:58 ` Carsten Dominik
2013-04-10 20:16 ` Sebastien Vauban
2013-04-11 2:58 ` Carsten Dominik
2013-04-11 17:30 ` Eli Zaretskii
2013-04-11 22:49 ` Carsten Dominik
2013-04-12 6:41 ` Eli Zaretskii
2013-04-12 7:13 ` Carsten Dominik
2013-04-12 8:31 ` Eli Zaretskii
2013-04-12 10:56 ` Carsten Dominik [this message]
2013-04-12 11:49 ` Torsten Wagner
2013-04-12 13:03 ` Eli Zaretskii
2013-04-12 18:00 ` Suvayu Ali
2013-04-12 18:38 ` Eli Zaretskii
2013-04-13 10:50 ` Suvayu Ali
2013-04-12 12:36 ` Eli Zaretskii
2013-04-13 12:24 ` Sean O'Halpin
2013-04-13 14:38 ` Jambunathan K
2013-04-13 15:01 ` Eli Zaretskii
2013-04-12 8:35 ` Bastien
2013-04-12 14:45 ` François Pinard
2013-04-18 20:37 ` Samuel Wales
2013-04-11 17:27 ` Eli Zaretskii
2013-04-11 22:46 ` Carsten Dominik
2013-04-10 12:12 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FFA190FA-6F2E-4983-AD4E-7D0F60378AE4@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).