From: Carlos Pita <carlosjosepita2@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Date: Thu, 18 Nov 2021 08:04:43 -0300 [thread overview]
Message-ID: <CAEOO5TdSb38QoKUEfTtEJQ3g3Xo+RozDBtnWeTXSgXAxhnY6uQ@mail.gmail.com> (raw)
In-Reply-To: <87h7c992p4.fsf@localhost>
Hi Ihor,
On Thu, Nov 18, 2021 at 7:28 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
> Carlos Pita <carlosjosepita2@gmail.com> writes:
>
> > I see no reason why a match inside b2 will hide b1 and b3 but not a
> > and c (I'm referring to the headings, not the contents).
>
> I think you misread the docstring for org-show-context-detail:
Sorry, I don't concur here.
This is in the docstring I'm interested in (org-occur):
The tree will show the lines where the regexp matches, and any other context
defined in ‘org-show-context-detail’, which see.
It might be that org-show-context-detail is used for org-reveal, but
this says it's also used for org-occur, which makes sense.
Besides, there is
occur-tree when using the command ‘org-occur’ (‘C-c / /’)
as a context for org-show-context-detail and it indeed makes a
difference in what is shown and what is hidden.
> This variable does not control how much text is hidden, but rather how
> much context is revealed around a folded text.
> Your misunderstanding may come from the fact that you are interested in
> org-occur, which first folds everything inside lowest-level headings.
It's not very relevant to my concern if things are first hidden and
then revealed, because that will just change my question to why
top-levels are not hidden to begin with. Again:
The tree will show the lines where the regexp matches, and any other context
defined in ‘org-show-context-detail’, which see.
The top-level headings in my example don't match the regexp and are
not part of the context that org-show-context-detail should reveal
with my current configuration. I cannot help concluding that this fact
contradicts the documentation.
Moreover, even if a escape clause were found in the documentation, the
examples I've presented show a behavior that is clearly different for
the top-level compared to any other level and that alone calls for
some kind of explanation IMO, as it is now it seems arbitrary, perhaps
there is an obvious reason for this that I'm failing to grasp.
> Consider agenda views. The relevant default value in
I indeed considered the agenda, but I prefer using a sparse tree. I
have a file with a large number of brief notes in top level headings
and it's useful to see the expanded matching notes, the behaviour of
org-occur is ideal in this regard, instead the agenda only shows the
headings and even in follow mode it's more cumbersome than merely
pressing M-g n/p directly in the target buffer. The problem I have now
is that hundreds of unmatching headings are still shown just because
they happen to be at the top-level. I see I could demote them or just
use the agenda, it's no big deal after all. But because of all the
reasons above I judge that the current behavior is not right, that's
the reason for my report. Nevertheless, thank you for your
suggestions, as always.
Best regards,
Carlos
next prev parent reply other threads:[~2021-11-18 11:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 19:15 [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)] Carlos Pita
2021-11-17 14:20 ` Ihor Radchenko
2021-11-17 21:01 ` Carlos Pita
2021-11-17 21:21 ` Carlos Pita
2021-11-18 10:29 ` Ihor Radchenko
2021-11-18 11:04 ` Carlos Pita [this message]
2021-11-18 11:49 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEOO5TdSb38QoKUEfTtEJQ3g3Xo+RozDBtnWeTXSgXAxhnY6uQ@mail.gmail.com \
--to=carlosjosepita2@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).