Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales samolog...@gmail.com writes: looks good. thanks for your effort on making a single variable. Pushed with tests and documentation, in 4eb4f47141a1ac582330b903bd779dccbcb1c154. Thank you. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales samolog...@gmail.com writes: that is not canonical. i thought we were working from my previous posts over the years where i used the term canonical. you cannot create the visibility state you show from a fully-folded buffer using only arrow keys and tab. You are right. Time for a third round, I guess. This patch removes `full', which is useless, makes `canonical' really canonical, and adds `tree' view, which is basically old wrong `canonical'. Original buffer, full view * Grandmother ** Uncle *** Heir ** Father Ancestor text *** Sister Sibling text *** Self Match First born Child text The other child *** Brother ** Aunt `minimal' * Grandmother *** Self Match `local' * Grandmother *** Self Match First born `ancestors' * Grandmother ** Father *** Self Match `lineage' * Grandmother ** Father *** Sister *** Self Match First born *** Brother `tree' * Grandmother ** Uncle ** Father *** Sister *** Self Match First born The other child *** Brother ** Aunt `canonical' * Grandmother ** Uncle ** Father Ancestor text *** Sister *** Self Match First born The other child *** Brother ** Aunt Regards, From 6f903362065ab34bcf3a85658d2f2f178e1ecb78 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou m...@nicolasgoaziou.fr Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering six different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++-- lisp/org.el| 230 ++--- 2 files changed, 118 insertions(+), 127 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..7adf351 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline. (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (optional n) Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children - subtree - folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children - subtree - folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there. (unless (bolp) (insert \n)) (unless (org-looking-at-p ^[ \t]*$) (save-excursion (insert \n))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'lineage)) (defun org-agenda-diary-entry () Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..1b20d50 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,80 @@ effective. :tag Org Reveal Location :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag Always t) -(const :tag Never nil) -(repeat :greedy t :tag Individual contexts - (cons - (choice :tag Context - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - Contexts for the reveal options.) - -(defcustom org-show-hierarchy-above '((default . t)) - Non-nil means show full hierarchy when revealing a location. -Org-mode often shows locations in an org-mode file which might have -been invisible before. When this is set, the hierarchy of headings -above the exposed location is shown. -Turning this off for example for sparse trees makes them very compact. -Instead of t, this can also be an alist specifying this option for different -contexts. Valid contexts are +(defcustom org-show-context-detail '((isearch . lineage) + (bookmark-jump .
Re: [O] [RFC] Simplify `org-show-context' configuration
looks good. thanks for your effort on making a single variable.
Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales samolog...@gmail.com writes: it would be good to also have semi-canonical [i.e. canonical-without-ancestor-body-text], where ancestor nodes do not show body text. text can obscure structure. i use this view for blogs. otherwise i'd have to make fake headlines just to hide text. I don't understand. Body text is not shown in ancestors. Considering the following buffer: * Grandmother ** Uncle *** Heir ** Father Ancestor text *** Sister Sibling text *** Self Match First born Child text The other child *** Brother ** Aunt `canonical' view is * Grandmother ** Uncle ** Father *** Sister *** Self Match First born The other child *** Brother ** Aunt does full show the entry below the headline that point is on? i wouldn't use this view if it is not canonical [i.e. does not show children also]. `full', as its name suggests, shows complete subtree: all children and their contents. do we presume that the entire buffer's visibility is changed for showing context, or are things that already shown left showing? `canonical' change visibilty in subtree, so some parts of it could be hidden in the process. Other views only augment current visibility. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Eric Abrahamsen wrote: Sebastien Vauban writes: Nicolas Goaziou wrote: Sebastien Vauban writes: Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. I have no strong opinion about this, but I think it would be odd if they were invisible. After all, this is the basic structure of the document. Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them when you have a lot of level-1 sections -- I remember that being asked here by someone. But, once again, for me, it's not that important. I'd prefer not to do that -- it's easy to get confused, and we've got narrowing when we need to really focus. Well, I never said it had to be the only (or default) behavior... Just mentioning that some people express that wish, from time to time. But I won't push for it. Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Simplify `org-show-context' configuration
Actually, the first patch didn't pay attention to children, if any, of the current headline. Here is a new patch, including feedback from Kyle and Sébastien. Considering the following buffer, Text being the matched location * Grandmother ** Uncle *** Heir ** Father *** Sister *** Self Text First born Other text The other child *** Brother ** Aunt `minimal' is * Grandmother *** Self Text `local' is * Grandmother *** Self Text First born `ancestors' is * Grandmother ** Father *** Self Text `lineage' is * Grandmother ** Father *** Sister *** Self Text First born *** Brother `canonical' is * Grandmother ** Uncle ** Father *** Sister *** Self Text First born The other child *** Brother ** Aunt `full' is * Grandmother ** Uncle ** Father *** Sister *** Self Text First born Other text The other child *** Brother ** Aunt Regards, -- Nicolas Goaziou From 7108b6a5fc2332f05979796af734b1d55e7a8172 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou m...@nicolasgoaziou.fr Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering six different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++-- lisp/org.el| 228 + 2 files changed, 114 insertions(+), 129 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..7adf351 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline. (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (optional n) Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children - subtree - folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children - subtree - folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there. (unless (bolp) (insert \n)) (unless (org-looking-at-p ^[ \t]*$) (save-excursion (insert \n))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'lineage)) (defun org-agenda-diary-entry () Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..c707ff4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,72 @@ effective. :tag Org Reveal Location :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag Always t) -(const :tag Never nil) -(repeat :greedy t :tag Individual contexts - (cons - (choice :tag Context - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - Contexts for the reveal options.) - -(defcustom org-show-hierarchy-above '((default . t)) - Non-nil means show full hierarchy when revealing a location. -Org-mode often shows locations in an org-mode file which might have -been invisible before. When this is set, the hierarchy of headings -above the exposed location is shown. -Turning this off for example for sparse trees makes them very compact. -Instead of t, this can also be an alist specifying this option for different -contexts. Valid contexts are +(defcustom org-show-context-detail '((isearch . lineage) + (bookmark-jump . lineage) + (default . ancestors)) + Alist between context and visibility span when revealing a location. + +\\org-mode-mapSome actions may move point into invisible +locations. As a consequence, Org always expose a neighborhood +around point. How much is shown depends on
Re: [O] [RFC] Simplify `org-show-context' configuration
Hello Nicolas, Nicolas Goaziou wrote: As explained in its commit message, the following patch is an attempt at simplifying `org-show-context' configuration by offering a set of 5 predefined views to choose from instead of setting 4 different variables (`org-show-following-heading', `org-show-siblings', `org-show-entry-below' and `org-show-hierarchy-above'). These views are minimalshow current headline, and entry below if needed local show current headline, entry below and next headline lineageshow direct ancestors and all siblings of current headline; show entry only if required canonical show direct ancestors and all of their siblings; show entry only if required full show direct ancestors, all their siblings and entry To sum it up, if original buffer is * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 and match is on Text, minimal is * H1 * H2 * Sub sub 2 Text `local' is * H1 * H2 *** Sub sub 2 Text *** Sub sub 3 `lineage' is * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 `canonical' and `full' are * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 Note that neither `canonical' nor `full' are possible to obtain with the 4 original variables. Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. if required/if needed means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? My /personal/ preference is to see the ancestors, so that I can know which path lead to the entry, and avoid confusion in case some sub sub sections are repeated in many different sub sections. With your proposal, I then only have the choice between `lineage', `full' and `canonical', while I'd like something which would give me: --8---cut here---start-8--- * H1 * H2 ** Sub 2 *** Sub sub 2 Text --8---cut here---end---8--- WDYT? Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Simplify `org-show-context' configuration
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. I have no strong opinion about this, but I think it would be odd if they were invisible. After all, this is the basic structure of the document. if required/if needed means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? My /personal/ preference is to see the ancestors, so that I can know which path lead to the entry, and avoid confusion in case some sub sub sections are repeated in many different sub sections. With your proposal, I then only have the choice between `lineage', `full' and `canonical', while I'd like something which would give me: * H1 * H2 ** Sub 2 *** Sub sub 2 Text WDYT? I can add `ancestors' view, which would basically be `lineage' without siblings. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
hi nicolas, On 2/17/15, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: I don't understand. Body text is not shown in ancestors. Considering the following buffer: * Grandmother ** Uncle *** Heir ** Father Ancestor text *** Sister Sibling text *** Self Match First born Child text The other child *** Brother ** Aunt `canonical' view is * Grandmother ** Uncle ** Father *** Sister *** Self Match First born The other child *** Brother ** Aunt thanks for showing a complete example. that is not canonical. i thought we were working from my previous posts over the years where i used the term canonical. you cannot create the visibility state you show from a fully-folded buffer using only arrow keys and tab. there are exactly two types of visibility. each type has many variants in principle, but we only need a few for each. 1] can be created using arrows and tab from a fully-folded buffer 2] cannot this is a critical distinction. org so far is not capable of doing any of the [1] states when going to a location. that's the problem that needs solving imo. i actually don't care about any of the [2] states until [1] is possible. within [1], there is a minimal state. let's call it minimal-canonical. /that/ is the state that is most needed. it's roughly like what you show except with the body text for all ancestors. what you show is [2]. it is a great view, and needed, but it is not minimal-canonical. i don't want the term canonical to be used for any of the [2] states, because then we will be back to missing the need for the minimal-canonical view and the need for preserving an org buffer's [1] status. hope that clarifies. samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] [RFC] Simplify `org-show-context' configuration
Nicolas Goaziou wrote: Sebastien Vauban writes: Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. I have no strong opinion about this, but I think it would be odd if they were invisible. After all, this is the basic structure of the document. Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them when you have a lot of level-1 sections -- I remember that being asked here by someone. But, once again, for me, it's not that important. if required/if needed means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? My /personal/ preference is to see the ancestors, so that I can know which path lead to the entry, and avoid confusion in case some sub sub sections are repeated in many different sub sections. With your proposal, I then only have the choice between `lineage', `full' and `canonical', while I'd like something which would give me: * H1 * H2 ** Sub 2 *** Sub sub 2 Text WDYT? I can add `ancestors' view, which would basically be `lineage' without siblings. That'd certainly be good -- and match my current Org config. And, if I may, to be sure we are somehow symmetrical, it'd be good to have as well: --8---cut here---start-8--- * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 --8---cut here---end---8--- That is ancestors + the siblings of the leaf entry. Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Simplify `org-show-context' configuration
Sebastien Vauban sva-n...@mygooglest.com writes: Nicolas Goaziou wrote: Sebastien Vauban writes: Question: are the level-1 headlines always visible, all of them I mean? I know that's the case as of now, but wondered if it'd be good to hide the ones which are not significant. Not a very sharp advice on this, though. I have no strong opinion about this, but I think it would be odd if they were invisible. After all, this is the basic structure of the document. Yes, that's why I'm not so pushy about it. OTOH, it's nice to hide them when you have a lot of level-1 sections -- I remember that being asked here by someone. But, once again, for me, it's not that important. I'd prefer not to do that -- it's easy to get confused, and we've got narrowing when we need to really focus. if required/if needed means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? My /personal/ preference is to see the ancestors, so that I can know which path lead to the entry, and avoid confusion in case some sub sub sections are repeated in many different sub sections. With your proposal, I then only have the choice between `lineage', `full' and `canonical', while I'd like something which would give me: * H1 * H2 ** Sub 2 *** Sub sub 2 Text WDYT? I can add `ancestors' view, which would basically be `lineage' without siblings. That'd certainly be good -- and match my current Org config. And, if I may, to be sure we are somehow symmetrical, it'd be good to have as well: * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 That is ancestors + the siblings of the leaf entry. This is the view I'd be interested in having, as well. Thanks! Eric
[O] [RFC] Simplify `org-show-context' configuration
Hello, As explained in its commit message, the following patch is an attempt at simplifying `org-show-context' configuration by offering a set of 5 predefined views to choose from instead of setting 4 different variables (`org-show-following-heading', `org-show-siblings', `org-show-entry-below' and `org-show-hierarchy-above'). These views are minimalshow current headline, and entry below if needed local show current headline, entry below and next headline lineageshow direct ancestors and all siblings of current headline; show entry only if required canonical show direct ancestors and all of their siblings; show entry only if required full show direct ancestors, all their siblings and entry To sum it up, if original buffer is * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 and match is on Text, minimal is * H1 * H2 * Sub sub 2 Text `local' is * H1 * H2 *** Sub sub 2 Text *** Sub sub 3 `lineage' is * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 `canonical' and `full' are * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 Note that neither `canonical' nor `full' are possible to obtain with the 4 original variables. if required/if needed means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? Regards, -- Nicolas Goaziou0x80A93738 From c04351a77a7d3af99d292f71e33d43f7e72410d2 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou m...@nicolasgoaziou.fr Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering five different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++--- lisp/org.el| 190 ++--- 2 files changed, 86 insertions(+), 119 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..f7406d7 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline. (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (optional n) Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children - subtree - folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children - subtree - folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there. (unless (bolp) (insert \n)) (unless (org-looking-at-p ^[ \t]*$) (save-excursion (insert \n))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'canonical)) (defun org-agenda-diary-entry () Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..bbabb9a 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,67 @@ effective. :tag Org Reveal Location :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag Always t) -(const :tag Never nil) -(repeat :greedy t :tag Individual contexts - (cons - (choice :tag Context - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - Contexts for the reveal options.) - -(defcustom org-show-hierarchy-above '((default . t)) - Non-nil means show full hierarchy when revealing a location. -Org-mode often shows
Re: [O] [RFC] Simplify `org-show-context' configuration
Kyle Meyer k...@kyleam.com writes: Thanks for the feedback. Minor: It took me some extra effort to parse this sentence because I'm not used to seeing 'respectively' used in this way. I think something like below is more common. As special cases, a nil or t value means show all contexts in `minimal' or `full' view, respectively. Updated. Thank you. (defun org-reveal (optional siblings) Show current entry, hierarchy above it, and the following headline. -This can be used to show a consistent set of context around locations -exposed with `org-show-hierarchy-above' or `org-show-following-heading' -not t for the search context. + +This can be used to show a consistent set of context around +locations exposed with `org-show-context'. With optional argument SIBLINGS, on each level of the hierarchy all siblings are shown. This repairs the tree structure to what it would Does a single C-u serve a purpose anymore? Without it, it is `lineage' view. With it, it is `canonical' (but I forgot to update it). I'm not sure we need the distinction however. Also, I'm not sure how useful double C-u is. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Nicolas Goaziou m...@nicolasgoaziou.fr wrote: As explained in its commit message, the following patch is an attempt at simplifying `org-show-context' configuration by offering a set of 5 predefined views to choose from instead of setting 4 different variables (`org-show-following-heading', `org-show-siblings', `org-show-entry-below' and `org-show-hierarchy-above'). These views are minimalshow current headline, and entry below if needed local show current headline, entry below and next headline lineageshow direct ancestors and all siblings of current headline; show entry only if required canonical show direct ancestors and all of their siblings; show entry only if required full show direct ancestors, all their siblings and entry [...] I think this is enough, but I can add more views if needed. WDYT? I prefer this to the old setup. From a configuration standpoint, it's much nicer to have all the relevant information in one variable. [...] +As a special case, a nil (respectively t) value means +`minimal' (respectively `full') detail level for all contexts. Minor: It took me some extra effort to parse this sentence because I'm not used to seeing 'respectively' used in this way. I think something like below is more common. As special cases, a nil or t value means show all contexts in `minimal' or `full' view, respectively. [...] (defun org-reveal (optional siblings) Show current entry, hierarchy above it, and the following headline. -This can be used to show a consistent set of context around locations -exposed with `org-show-hierarchy-above' or `org-show-following-heading' -not t for the search context. + +This can be used to show a consistent set of context around +locations exposed with `org-show-context'. With optional argument SIBLINGS, on each level of the hierarchy all siblings are shown. This repairs the tree structure to what it would Does a single C-u serve a purpose anymore? -- Kyle
