Re: Enriched/Org is a colorful Org

[Carsten Dominik <carsten.dominik@gmail.com>]

On 10.4.2013, at 22:16, "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On 10.4.2013, at 18:21, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> From: Carsten Dominik <carsten.dominik@gmail.com>
>>>> On 10 apr. 2013, at 11:54, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
>>>>> This request is common enough; every time it comes up overlays are
>>>>> proposed as a solution.  It would be good if this is available even as a
>>>>> library outside of Org.
>>>> 
>>>> Yes, overlays are better.
>>> 
>>> I beg the Org developers to please be very careful when introducing
>>> expensive display features such as overlays into Org.  Org already
>>> puts the Emacs display engine to its limits in many of its popular
>>> features;
>> 
>> this is interesting input, I was not aware of this. Has this been discussed
>> before, can you point me to relevant threads, and what are the symptoms of the
>> display engine being at its limits?
>> 
>>> adding overlays to this mess might be too much.
> 
> I guess Eli simply means, in a general way, that overlays do negatively impact
> display performance, as you said as well a couple of times:

Yes, but Eli says that Org already severely tests the
display engine, and he uses the word "mess", even though
we mostly use text properties for faces and other
display-related things.  So I was wondering if there is
something we should put onto our todo list.

Of course, Org already uses overlays, for example for
folding (as does outline.el), and for temporary marking
of text like during src block editing.  But as your digging
shows, I ave avoided them in the past, and we are also not
using them for org-indent.el, for example.

The reason why I said "overlays would be better" is simply
that they would allow to add display properties in a
persistent way that would not interfere that our
font-lock-unfontify-region function removes face and
invisibility text properties.  So they are "better" for
implementing hand-made faces selection that should overrule
font-lock.

- Carsten


> 
>  ╭────
>  │ From: Carsten Dominik <carsten.dominik@gmail.com>
>  │ Subject: Re: performance problems with drawers
>  │ Newsgroups: gmane.emacs.orgmode
>  │ To: Al <gmane00@wilec.net>
>  │ Cc: emacs-orgmode@gnu.org
>  │ Date: Wed, 8 Jul 2009 07:05:53 +0200 (3 years, 39 weeks, 3 days ago)
>  │ 
>  │ Hi Al,
>  │ 
>  │ first of all, I cannot reproduce the fact that drawers have such
>  │ a major influence on time, wit a test file that I created to
>  │ be similar to what you describe.
>  │ 
>  │ There is a way to speed up drawer handling, by using text properties
>  │ instead of overlays.  How have some vague plans to do this, but nothing
>  │ concrete or soon.
>  │ 
>  │ - Carsten
>  ╰────
> 
> and
> 
>  ╭────
>  │ From: Carsten Dominik <carsten.dominik@gmail.com>
>  │ Subject: Re: fontification and icon issues
>  │ Newsgroups: gmane.emacs.orgmode
>  │ To: David O'Toole <dto1138@gmail.com>
>  │ Cc: emacs-orgmode@gnu.org
>  │ Date: Thu, 24 Sep 2009 10:46:24 +0100 (3 years, 28 weeks, 2 days ago)
>  │ 
>  │ On Sep 22, 2009, at 4:11 PM, David O'Toole wrote:
>  │ > [...]
>  │ >
>  │ > 2. using add-text-properties to specify a display property (or even just
>  │ > a face) for any part of an org headline text kills the fontification of
>  │ > the rest of the text (TODO keyword and leading stars unaffected.) I'm
>  │ > trying to use font-lock-add-keywords to display the images.
>  │ 
>  │ Can you make an example file, and maybe a small function that does set these
>  │ properties, so that I can see what you mean?
>  │ 
>  │ - Carsten
>  │ 
>  │ > Maybe I should use overlays instead?
>  │ 
>  │ This can be done, but if every line in a very large file gets
>  │ an overlay, performance is severely degraded.
>  │ 
>  │ - Carsten
>  ╰────
> 
>>> I don't know enough about Org to understand why overlays are being
>>> considered instead of text properties, but feel free to describe the
>>> issues (preferably on emacs-devel) and start a discussion about the
>>> possible alternatives.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
>