Matt Price writes:
> Is this code in main now, and do I have to do anything special to test it
> out?
Not on main yet. I need maintainers to agree about the merge. It is a
major change. I plan to prepare a proper patchset and bump the thread
again a few weeks later, when the dust settles on the
On Tue, Sep 21, 2021 at 9:36 AM Timothy wrote:
> I’m suspect it too short notice for such a large change to make its way
> into Org
> 9.5, but Bastien’s release email is certainly a good prompt to bump this.
>
> Bastien writes:
>
> > Thank you *very much* for this work and sorry for the slow rep
I’m suspect it too short notice for such a large change to make its way into Org
9.5, but Bastien’s release email is certainly a good prompt to bump this.
Bastien writes:
> Thank you *very much* for this work and sorry for the slow reply.
>
> I urge everyone to test this change, as I’d like to i
Hi Ihor,
Ihor Radchenko writes:
> This is another update about the status of the patch.
Thank you *very much* for this work and sorry for the slow reply.
I urge everyone to test this change, as I'd like to include it in
Org 9.5 if it's ready.
I will test this myself this week and report.
Tha
Hello,
This is another update about the status of the patch.
I am mostly happy with the current state of the code, got rid of most of
the bugs, and did not get any new bug reports in github for a while.
I would like to start the process of applying the patch on master.
As a first step, I would l
Hello,
This is an update about the current status of the patch.
Since there was not much feedback, I decided to share the up-to-date
branch on github, so that people can directly download/clone the whole
thing and load it to Emacs without a need to install the patch manually.
The github repo is
> I understand from your answer to Bastien's query that this fix is
> specific to your branch; would it be hard to backport it to Org's maint
> branch? Otherwise IIUC Org 9.4 will keep this regression, and users
> will have to wait until Org 9.5 for a fix.
The problem is that fix in my branch has
Ihor Radchenko writes:
> Thanks for reporting! I accidentally reintroduced the bug because of
> mistake when converting org-hide-drawers to new folding library.
> (:facepalm:).
>
> Should be fixed in the gist now.
Can confirm, thanks!
I understand from your answer to Bastien's query that this f
> Can you share this gist as a patch against Org's current master?
That is not possible. The underlying reason of the bug in the patch is
different from master.
On master, the overlays for folded drawers and headlines are merged
together - when folded headline is opened by isearch, everything is
Hi Ihor,
Ihor Radchenko writes:
> Thanks for reporting! I accidentally reintroduced the bug because of
> mistake when converting org-hide-drawers to new folding library.
> (:facepalm:).
>
> Should be fixed in the gist now.
Can you share this gist as a patch against Org's current master?
--
B
> Apologies for maybe changing the subject, but earlier this summer you
> mentioned[1] you were working on a patch to the folding system that
> would fix an issue I have[2] with LOGBOOKs since 9.4. AFAICT the patch
> you are sharing now does not fix that; is this issue still on your
> radar?
Than
Ihor Radchenko writes:
>>> then M-x toggle-debug-on-error and M-: (org-make-manuals), but I can't
>>> get a stacktrace. I'm guessing this is because this error (which IIUC
>>> originates from org-back-to-heading in org.el) is a user-error; however,
>>> if I change the function to raise a "regula
>> then M-x toggle-debug-on-error and M-: (org-make-manuals), but I can't
>> get a stacktrace. I'm guessing this is because this error (which IIUC
>> originates from org-back-to-heading in org.el) is a user-error; however,
>> if I change the function to raise a "regular error", then everything
>>
> I get a conflict in org.el, on the hunk where org-reveal-location
> and org-show-context-detail are defined; since your patch just
> deletes them, I resolve this with:
That's because the patch was against 0afef17e1. The new version of the
patch (same URL) is against aea1109ef now.
>
Hi!
Ihor Radchenko writes:
> The current version of the patch (against master) is in
> https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
I'm probably missing something obvious, but when applying your patch on
top of master[1], make fails when generating manuals:
> emacs -Q -ba
Hello,
> There are still known problems though. The patch currently breaks many
> org-mode tests when running =make test=. It is partially because some
> tests assume overlays to be used for folding and partially because the
> patch appears to break certain folding conventions. I am still
> invest
>>> 'outline --> `outline
>>
>> Could you explain why?
>
> Compatibility. pcase learned that in Emacs 25, IIRC.
Thanks for the explanation. Fixed now in my local branch.
I will send the updated version of the patch after more edits unless
someone specifically need to fix this change to make patc
Ihor Radchenko writes:
>> 'outline --> `outline
>
> Could you explain why?
Compatibility. pcase learned that in Emacs 25, IIRC.
Hello,
[The patch itself will be provided in the following email or can be accessed
via Github [1]]
I have finally finished the suggested edits. Most importantly:
- All the folding-related code lives in =org-fold.el= and =org-cycle.el= now.
- =org-fold.el= have commentary section explaining how
Hello,
Ihor Radchenko writes:
> I am currently working on org-fold.el. However, I am not sure if it is
> acceptable to move some of the existing functions from org.el to
> org-fold.el.
>
> Specifically, functions from the following sections of org.el might be
> moved to org-fold.el:
>> ;;; Visib
> Once done, I think we should move (or copy, first) _all_ folding-related
> functions into a new "org-fold.el" library. Functions and variables
> included there should have a proper "org-fold-" prefix. More on this in
> the detailed report.
I am currently working on org-fold.el. However, I am not
Hello,
Ihor Radchenko writes:
> [The patch itself will be provided in the following email]
Thank you! I'll first make some generic remarks, then comment the diff
in more details.
> I have four more updates from the previous version of the patch:
>
> 1. All the code handling modifications in fo
Github link to the patch:
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
Ihor Radchenko writes:
> Hello,
>
> [The patch itself will be provided in the following email]
>
> I have four more updates from the previous version of the patch:
>
> 1. All the code handling modificati
The patch (against 1aa095ccf) is attached.
diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
index 9f8677871..ab470ea9b 100644
--- a/contrib/lisp/org-notify.el
+++ b/contrib/lisp/org-notify.el
@@ -246,7 +246,7 @@ seconds. The default value for SECS is 20."
(switch-to
Hello,
[The patch itself will be provided in the following email]
I have four more updates from the previous version of the patch:
1. All the code handling modifications in folded drawers/blocks is moved
to after-change-function. It works as follows:
- if any text is inserted in the middle
Ihor Radchenko writes:
>> See also `gensym'. Do we really need to use it for something else than
>> `invisible'? If not, the tool doesn't need to be generic.
>
> For now, I also use it for buffer-local 'invisible stack. The stack is
> needed to preserve folding state of drawers/blocks inside fold
> See also `gensym'. Do we really need to use it for something else than
> `invisible'? If not, the tool doesn't need to be generic.
For now, I also use it for buffer-local 'invisible stack. The stack is
needed to preserve folding state of drawers/blocks inside folded
outline. Though I am thinking
Hello,
Ihor Radchenko writes:
> [The patch itself will be provided in the following email]
Thank you.
> I have found char-property-alias-alist variable that controls how Emacs
> calculates text property value if the property is not set. This variable
> can be buffer-local, which allows indepen
> Oh, I thought this was already done. Do you need to submit the form
> or do you wait for the FSF confirmation?
Need to submit.
Bastien writes:
> Hi Ihor,
>
> Ihor Radchenko writes:
>
>>> Thanks -- just a quick note, in case you missed the message: we are in
>>> feature free for core functio
Hi Ihor,
Ihor Radchenko writes:
>> Thanks -- just a quick note, in case you missed the message: we are in
>> feature free for core functionalities, so we have time to work on this
>> welcome enhancement for Org 9.5, which will give us time to properly
>> test it too.
>
> I do not expect it to b
> Thanks -- just a quick note, in case you missed the message: we are in
> feature free for core functionalities, so we have time to work on this
> welcome enhancement for Org 9.5, which will give us time to properly
> test it too.
I do not expect it to be merged any time soon. The patch is modif
Hi Ihor,
Ihor Radchenko writes:
> The patch (against 758b039c0) is attached.
Thanks -- just a quick note, in case you missed the message: we are in
feature free for core functionalities, so we have time to work on this
welcome enhancement for Org 9.5, which will give us time to properly
test i
Github link to the patch:
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
Ihor Radchenko writes:
> Hello,
>
> [The patch itself will be provided in the following email]
>
> I have three updates from the previous version of the patch:
>
> 1. I managed to implement buffer-local
The patch (against 758b039c0) is attached.
diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
index 9f8677871..ab470ea9b 100644
--- a/contrib/lisp/org-notify.el
+++ b/contrib/lisp/org-notify.el
@@ -246,7 +246,7 @@ seconds. The default value for SECS is 20."
(switch-to
Hello,
[The patch itself will be provided in the following email]
I have three updates from the previous version of the patch:
1. I managed to implement buffer-local text properties.
Now, outline folding also uses text properties without a need to give
up independent folding in indirect bu
Hello,
Ihor Radchenko writes:
> I have five updates from the previous version of the patch:
Thank you.
> 1. I implemented a simplified version of element parsing to detect
> changes in folded drawers or blocks. No computationally expensive calls
> of org-element-at-point or org-element-parse-b
Github link to the patch:
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
Ihor Radchenko writes:
> The patch is attached
>
> diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
> index 9f8677871..ab470ea9b 100644
> --- a/contrib/lisp/org-notify.el
> +++ b/con
The patch is attached
diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
index 9f8677871..ab470ea9b 100644
--- a/contrib/lisp/org-notify.el
+++ b/contrib/lisp/org-notify.el
@@ -246,7 +246,7 @@ seconds. The default value for SECS is 20."
(switch-to-buffer (find-file-no
Hello,
[The patch itself will be provided in the following email]
I have five updates from the previous version of the patch:
1. I implemented a simplified version of element parsing to detect
changes in folded drawers or blocks. No computationally expensive calls
of org-element-at-point or org-
Hello,
Ihor Radchenko writes:
>> As you noticed, using Org Element is a no-go, unfortunately. Parsing an
>> element is a O(N) operation by the number of elements before it in
>> a section. In particular, it is not bounded, and not mitigated by
>> a cache. For large documents, it is going to be u
> As you noticed, using Org Element is a no-go, unfortunately. Parsing an
> element is a O(N) operation by the number of elements before it in
> a section. In particular, it is not bounded, and not mitigated by
> a cache. For large documents, it is going to be unbearably slow, too.
Ouch. I thought
Hello,
Ihor Radchenko writes:
> Apparently my previous email was again refused by your mail server (I
> tried to add patch as attachment this time).
Ah. This is annoying, for you and for me.
> The patch is in
> https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
Thank you.
>> I
Dear Nicolas Goaziou,
Apparently my previous email was again refused by your mail server (I
tried to add patch as attachment this time).
The patch is in
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef
This patch is actually one commit ahead of the patch in the email, fixing
an
Hi,
[All the changes below are relative to commit ed0e75d24. Later commits
make it hard to distinguish between hidden headlines and drawers. I will
need to figure out a way to merge this branch with master. It does not
seem to be trivial.]
I have finished a seemingly stable implementation of hand
Completing myself,
Nicolas Goaziou writes:
> Each syntactical element has a "sensitive part", a particular area that
> can change the nature of the element when it is altered. Luckily drawers
> (and blocks) are sturdy. For a drawer, there are three things to check:
>
> 1. the opening line must m
Ihor Radchenko writes:
> Currently, `org-flag-region' only removes one SPEC type of overlays:
>
> (remove-overlays from to 'invisible spec)
>
> If we change it to
>
> (remove-overlays from to 'invisible spec)
> (when flag
> (remove-overlays from to 'invisible 'org-hide-drawer)
> ...
> )
>
> then
Ihor Radchenko writes:
> This should be better:
> https://gist.github.com/yantar92/e37c2830d3bb6db8678b14424286c930
Thank you.
> This might get tricky in the following case:
>
> :PROPERTIES:
> :CREATED: [2020-04-13 Mon 22:31]
>
> :SHOWFROMDATE: 2020-05-11
> :ID: e05e3b33-71ba-4bbc-abba-8
> You're talking about "overview" (org-overview), whereas I'm talking
> about "contents view" (org-content). They are not the same. In the
> latter, you show every headline in the buffer, so you have one overlay
> per headline.
Thanks for the explanation. I finally understand you initial note.
I w
Ihor Radchenko writes:
> If you want, I can test the file without :LOGBOOK: lines tomorrow.
Don't worry, it doesn't matter now.
> No, there are only 9 'outline overlays in the folded buffer if we do not
> create overlays for drawers. This is because outline-hide-sublevels
> called by org-overvi
> 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
> I don't know how you made your test. You probably didn't
> remove :LOGBOOK: lines. When headlines are fully folded, there are
> 8 overlays in the buffer, where there used to be 10k. It cannot be
> a "small improvement".
Ouch. I did not remove :LOGBOOK: lines. I thought you referred to the
origin
Nicolas Goaziou writes:
> Ihor Radchenko 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-archi
Ihor Radchenko 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/emacs-orgmode@gnu.org/msg127972
Ihor Radchenko writes:
> I still do not feel much difference, so I used elp to quantify if there
> is any difference I cannot notice by myself. I tested the time to move
> from to bottom of the example file with next-logical-line.
>
> org master (7801e9236):
> 6(#calls) 2.852953989(tota
>> I tested with master + my personal config + native compilation of org,
>> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae.
>> Did not see much improvement.
>> Vertical motion in the folded buffer is still quite slow.
>
> Oh! This is embarrassing. I improved speed, then
Hello,
Ihor Radchenko writes:
>> Oops, you are right. I fixed this. It should be way faster. I can
>> navigate in your example file without much trouble.
>>
>> Please let me know how it goes.
>
> I tested with master + my personal config + native compilation of org,
> Emacs native-comp branch, c
> Oops, you are right. I fixed this. It should be way faster. I can
> navigate in your example file without much trouble.
>
> Please let me know how it goes.
I tested with master + my personal config + native compilation of org,
Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77
> Unfortunately, I don't see your patch.
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
The message landed on the mail list though:
https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972.html
Best,
Ihor
Ihor Radchenko writes:
> Note that the following commits seems to break my patch:
Unfortunately, I don't see your patch.
Hello,
Ihor Radchenko writes:
> Just tested the master branch.
> Three observations on large org file:
>
> 1. Next/previous line on folder buffer is still terribly slow
Oops, you are right. I fixed this. It should be way faster. I can
navigate in your example file without much trouble.
Please
Note that the following commits seems to break my patch:
074ea1629 origin/master master Deprecate `org-cycle-hide-drawers'
1027e0256 Implement `org-cycle-hide-property-drawers'
8b05c06d4 Use `outline' invisibility spec for property drawers
The patch should work for commit ed0e75d24 in master.
> As a follow-up, I switched property drawers (and only those) back to
> using `outline' invisible spec in master branch. Hopefully, navigating
> in large folded files should be faster.
Just tested the master branch.
Three observations on large org file:
1. Next/previous line on folder buffer is
> I am not sure I understand how your follow-up code (below) needs to be
> incorporated. Would you mind
> sending a patch file? I hope that this ends up in the master branch at some
> point.
I have sent the patch in another email.
Will appreciate any feedback.
Best,
Ihor
Christian Heinrich w
> The visual glitch looks like that:
>
> :PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54]
> X
Should be partially fixed in the latest patch I just sent.
OLD <<< :PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54]
NEW >>> :PROPERTIES:X X
Best,
Ihor
Karl Voit writes:
> Hi Ihor,
>
> * Ihor Radchenko
I have prepared a patch taking into account your comments and fixing
other issues, reported by Karl Voit and found by myself.
Summary of what is done in the patch:
1. iSearching in drawers is rewritten using using
isearch-filter-predicate and isearch-mode-end-hook.
The idea is to create temporary
Nicolas Goaziou writes:
> I wonder how it compares to drawers using the same invisible spec as
> headlines, as it was the case before. Could you give it a try?
>
> I think hiding all property drawers right after opening a subtree is
> fast enough.
As a follow-up, I switched property drawers (an
Hello,
Ihor Radchenko writes:
> ;; Unfortunately isearch, sets inhibit-point-motion-hooks and we
> ;; cannot even use cursor-sensor-functions as a workaround
> ;; I used a less ideas approach with advice to isearch-search-string as
> ;; a workaround
OK.
> (defun org-find-text-property-region
Hi,
thanks for your (initial) patch! I traced another error down today and found
your code by chance. I
tested it on an org-drill file that I had (with over 3500 items and hence 3500
drawers) and this
patch helps *a lot* already. (Performance broke in
4403d4685e19fb99ba9bfec2bd4ff6781c66981f wh
Hi,
* Karl Voit wrote:
> Hi Ihor,
>
> * Ihor Radchenko wrote:
>>
>> So far, I came up with the following partial solution searching and
>> showing hidden text.
>>
>> (defun org-find-text-property-region (pos prop)
>> (define-advice isearch-search-string (:after (&rest _) put-overlay)
>> (defun o
Hi Ihor,
* Ihor Radchenko wrote:
>
> So far, I came up with the following partial solution searching and
> showing hidden text.
>
> (defun org-find-text-property-region (pos prop)
> (define-advice isearch-search-string (:after (&rest _) put-overlay)
> (defun org-restore-invisibility-specs (&rest
> You cannot. You may however mimic it with `cursor-sensor-functions' text
> property. These assume Cursor Sensor minor mode is active, tho.
> I haven't tested it, but I assume it would slow down text properties
> a bit, too, but hopefully not as much as overlays.
Unfortunately, isearch sets inhib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nicolas Goaziou writes:
> Hello,
>
> Ihor Radchenko writes:
>
>> To my surprise, the patch did not break org to unusable state and
>> the performance on the sample org file [3] improved drastically. You can
>> try by yourself!
>
> It is not a sur
Hello,
Ihor Radchenko writes:
> To my surprise, the patch did not break org to unusable state and
> the performance on the sample org file [3] improved drastically. You can
> try by yourself!
It is not a surprise, really. Text properties are much faster than
overlays, and very close to them fea
Emacs becomes very slow when opening and moving around huge org files
with many drawers. I have reported this issue last year in bug-gnu-emacs
[1] and there have been other reports on the same problem in the
internet [2]. You can easily see this problem using the attached file if
you try to move do
74 matches
Mail list logo
