Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Unfortunately, reviewing this way is not nice.

This should be better:
https://gist.github.com/yantar92/e37c2830d3bb6db8678b14424286c930

> The `insert-and-inherit' issue sounds serious. We cannot reasonably
> expect any library outside Org to use it. 
>
> We could automatically extend invisible area with
> `after-change-functions', i.e., if we're inserting something and both
> side have the same `invisible' property, extend it. Using
> `after-change-functions' sounds bad, but this kind of check shouldn't
> cost much.
>
> WDYT?

This might get tricky in the following case:

:PROPERTIES:
:CREATED: [2020-04-13 Mon 22:31]
<region-beginning>
:SHOWFROMDATE: 2020-05-11
:ID:       e05e3b33-71ba-4bbc-abba-8a92c565ad34
:END:

<many subtrees in between>

:PROPERTIES:
:CREATED:  [2020-04-27 Mon 13:50]
<region-end>
:ID:       b2eef49f-1c5c-4ff1-8e10-80423c8d8532
:ATTACH_DIR_INHERIT: t
:END:

If the text in the region is replaced by something else, <many subtrees
in between> should not be fully hidden. We cannot simply look at the
'invisible property before and after the changed region. 

I think that using fontification (something similar to
org-fontify-drawers) instead of after-change-functions should be faster.

Best,
Ihor


Nicolas Goaziou <address@hidden> writes:

> Ihor Radchenko <address@hidden> writes:
>
>> My response to you was blocked by your mail server:
>>
>>> 550 5.7.1 Reject for policy reason RULE3_2. See
>>> http://postmaster.gandi.net
>
> Aka "spam detected". Bah.
>
>> The message landed on the mail list though:
>> https://www.mail-archive.com/address@hidden/msg127972.html
>
> Unfortunately, reviewing this way is not nice.
>
> The `insert-and-inherit' issue sounds serious. We cannot reasonably
> expect any library outside Org to use it. 
>
> We could automatically extend invisible area with
> `after-change-functions', i.e., if we're inserting something and both
> side have the same `invisible' property, extend it. Using
> `after-change-functions' sounds bad, but this kind of check shouldn't
> cost much.
>
> WDYT?
>
> Regards,

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: address@hidden, address@hidden