Ihor Radchenko <yanta...@gmail.com> 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 future, but
> that's not the priority now.
Mmm; is the current state of your branch representative of your plan?
If I compile it and run
emacs -Q -L $yourbranch/lisp --eval '(setq org-startup-folded t)'
$someorgfile
Then isearching does not reveal logbook drawers unless matches are found
inside, which as far as I am concerned fixes my issue with 9.4.
>> I wonder if the path of least resistance couldn't be found in
>> org-cycle-hide-drawers: right now this function just skips over drawers
>> which are covered with an invisible overlay, but maybe it should not
>> skip a drawer if the overlay starts before it (i.e. the overlay is not
>> specific to this drawer but covers a whole containing section).
>
> That would defeat the purpose why the number of overlays was reduced in
> Org 9.4. However, org-cycle-hide-drawers might be called in
> isearch-open-invisible-temporary.
Thanks for the tip.
