all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.