From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: three bugs/misfeatures in org-reveal (or is org-reveal the wrong way to reveal around point?)
Date: Sun, 18 Jan 2015 10:16:25 +0100 [thread overview]
Message-ID: <87oapwqwie.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <CAJcAo8v9FB2Mtpk_yZLvwZdii2yqDLyf7ERxoQdcKoFbieS7+w@mail.gmail.com> (Samuel Wales's message of "Sat, 17 Jan 2015 12:46:12 -0700")
Hello,
Samuel Wales <samologist@gmail.com> writes:
> thanks for clarifying. that seems to eliminate all possibility of
> specifying canonical visibility using org show variables.
Indeed.
> thus, this is a feature that is strangely missing in org, as opposed
> to a bug.
I agree. Also, I find the configuration in this area overly complicated.
> canonical visibility roughly means a visibility state that can be
> created at any time using org-cycle and arrow keys.
>
> for example, if only the first child is showing, then it is not
> canonical visibility. the only things that should NOT show are
> entirely folded headers, blocks, etc.
>
> this is the only kind of visibility that i ever use unless i am doing
> a sparse tree, which is extremely rare.
I think we could simplify the show context configuration and, at the
same time, provide a way to show "canonical visibility".
For example, we can merge `org-show-hierarchy-above',
`org-show-following-heading', `org-show-siblings' and
`org-show-entry-below' into a single variable,
`org-show-context-detail', where each context is associated to a level,
e.g., for current default configuration,
((default . 2)
(occur-tree . 1)
(tags-tree . 1)
(isearch . 3)
(bookmark-jump . 3))
where
1. means only the minimal location is shown, i.e., top level
headline + headline, and section (no child) if match is not on
a headline.
2. means context 1 + hierarchy above
3. means context 2 + siblings
4. means canonical view, i.e, show full hierarchy above and siblings,
and, if match is within a section, show also section and all
children.
We lose a bit of control, but I think left out combinations are not very
interesting. But I may be wrong.
WDYT?
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2015-01-18 9:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 22:50 three bugs/misfeatures in org-reveal (or is org-reveal the wrong way to reveal around point?) Samuel Wales
2013-08-06 7:41 ` Sebastien Vauban
2013-08-07 3:37 ` Samuel Wales
2015-01-17 1:23 ` Samuel Wales
2015-01-17 8:54 ` Nicolas Goaziou
2015-01-17 19:46 ` Samuel Wales
2015-01-18 9:16 ` Nicolas Goaziou [this message]
2015-01-18 20:26 ` Samuel Wales
2015-01-21 21:24 ` Nicolas Goaziou
2015-01-23 21:52 ` Samuel Wales
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=87oapwqwie.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=samologist@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).