Kévin Le Gouguec writes:
> Ihor Radchenko writes:
>
>> Kévin Le Gouguec writes:
>>
>>> 1.2. stumps me: is there an isearch API I can use while in the callback
>>> to know where the matches are located?
>>
>> I do not think that there is direct API for this, but the match should
>> be
Ihor Radchenko writes:
> Kévin Le Gouguec writes:
>
>> 1.2. stumps me: is there an isearch API I can use while in the callback
>> to know where the matches are located?
>
> I do not think that there is direct API for this, but the match should
> be accessible through match-beginning/match-end,
Kévin Le Gouguec writes:
> 1.2. stumps me: is there an isearch API I can use while in the callback
> to know where the matches are located?
I do not think that there is direct API for this, but the match should
be accessible through match-beginning/match-end, as I can see from the
isearch.el
Ihor Radchenko writes:
> However, org-cycle-hide-drawers might be called in
> isearch-open-invisible-temporary.
This callback receives two arguments:
- the overlay which contains a match,
- whether we are un-hiding the overlay's span or hiding it back.
To get the same behaviour as
Kévin Le Gouguec writes:
> Ihor Radchenko writes:
>
>> My current plan is supporting the overlay-based approach even after
>> merging the branch (by default). So, overlays should be around for a
>> while and the issue with drawer visibility will be around as well,
>> unless you fix it. I will
Ihor Radchenko writes:
> My current plan is supporting the overlay-based approach even after
> merging the branch (by default). So, overlays should be around for a
> while and the issue with drawer visibility will be around as well,
> unless you fix it. I will probably work on this in distant
Kévin Le Gouguec writes:
> I've looked at your branch for inspiration, and my takeaway is that the
> isearch-open-invisible-temporary route might be too involved for a
> bugfix, especially if it's going to be reverted wholesale when your
> branch gets merged. Then again, maybe I'm not smart
Ihor Radchenko writes:
> Kévin Le Gouguec writes:
>
>> Since the changes in Org 9.4 aimed at improving performance, is there a
>> test case somewhere in the "Mitigating the poor Emacs performance on
>> huge org files" thread that could help ensure that a tentative fix will
>> not degrade
Kévin Le Gouguec writes:
> Since the changes in Org 9.4 aimed at improving performance, is there a
> test case somewhere in the "Mitigating the poor Emacs performance on
> huge org files" thread that could help ensure that a tentative fix will
> not degrade performance?
The first message in the
Ihor Radchenko writes:
> You will probably need to implement this from scratch (or use the
> feature/org-fold branch from github.com/yantar92/org).
Gotcha. TBH I don't know if I'll have the time to cook up a patch
before 27.2 is released; all the same, I appreciate you taking the time
to
Kévin Le Gouguec writes:
> I can't find any reference to this property in Org <9.4 (e.g. 9.3 as
> shipped in 27.1, where the bug does not happen) so do I understand
> correctly that the root cause ("since [drawers] are in the same overlay
> with the rest of the folded heading") dates from Org
Ihor Radchenko writes:
> Kévin Le Gouguec writes:
>
>> The debugger only fires *after* we exit isearch, and by that time it's
>> too late: my issue comes from all those logbooks cluttering the screen
>> while I'm mashing C-s to iterate through matches.
>>
>> I can try to dig deeper into this,
Kévin Le Gouguec writes:
> The debugger only fires *after* we exit isearch, and by that time it's
> too late: my issue comes from all those logbooks cluttering the screen
> while I'm mashing C-s to iterate through matches.
>
> I can try to dig deeper into this, but before doing so: would you
13 matches
Mail list logo
