Re: [O] Behavior of `org-show-entry'
Nicolas Goaziouwrites: > Hello, > > Kyle Meyer writes: > >> Hmm, for the reason I gave above, I don't think org-show-entry should >> change, but perhaps there should be a separate function that does >> >> (org-show-entry) >> (org-with-limited-levels (org-show-children)) >> >> which is what org-cycle does for the second state listed in its >> docstring. Or maybe there is a better way to accomplish this that I >> don't know about. > > See `org-show-context' and `org-reveal'. Thanks to you both -- I'll bring this up with the Helm people. Eric
Re: [O] Behavior of `org-show-entry'
Nicolas Goaziouwrites: > Kyle Meyer writes: > >> Hmm, for the reason I gave above, I don't think org-show-entry should >> change, but perhaps there should be a separate function that does >> >> (org-show-entry) >> (org-with-limited-levels (org-show-children)) >> >> which is what org-cycle does for the second state listed in its >> docstring. Or maybe there is a better way to accomplish this that I >> don't know about. > > See `org-show-context' and `org-reveal'. Sadly, I had already seen these, and I still answered what I did :) It seems like, with the default value of org-show-context-detail, (org-show-context 'agenda) will show the desired view of * a a body ** aa... * b So, do you recommend that, assuming helm wants this view after jumping to a heading, it calls (org-show-set-visibility 'local)? Or should it use its own key, something like (org-show-context 'helm), so that users can customize the key in org-show-context-detail? Or something else? Thanks. -- Kyle
Re: [O] Behavior of `org-show-entry'
Hello, Kyle Meyerwrites: > Hmm, for the reason I gave above, I don't think org-show-entry should > change, but perhaps there should be a separate function that does > > (org-show-entry) > (org-with-limited-levels (org-show-children)) > > which is what org-cycle does for the second state listed in its > docstring. Or maybe there is a better way to accomplish this that I > don't know about. See `org-show-context' and `org-reveal'. Regards, -- Nicolas Goaziou
Re: [O] Behavior of `org-show-entry'
Eric Abrahamsenwrites: > Kyle Meyer writes: [...] >> Based on how org-show-entry calls it, outline-flag-region shows the text >> from the current heading to the next. So it seems to behave as >> documented: "[s]how the body directly following this heading". > > Okay, but I still don't see how this would ever be the desired result. > You can't get to *any* next visibility state without first wasting a > . Yeah, fair enough. I can't think of a situation where I would desire that result either. But I think org-show-entry probably should behave this way to be consistent with outline-show-entry. >>> Which part of this should be tweaked to achieve the desired effect? >> >> Perhaps helm could call org-show-children after it calls org-show-entry. > > Okay, cool. I guess my main question was: should this be fixed in helm, > or in org? I'll try clobbering the helm functions for a while and see > how that goes, then raise this on the helm list. Hmm, for the reason I gave above, I don't think org-show-entry should change, but perhaps there should be a separate function that does (org-show-entry) (org-with-limited-levels (org-show-children)) which is what org-cycle does for the second state listed in its docstring. Or maybe there is a better way to accomplish this that I don't know about. -- Kyle
Re: [O] Behavior of `org-show-entry'
Kyle Meyerwrites: > Eric Abrahamsen writes: > >> I do a lot of my Org navigation with `helm-org-in-buffer-headings' and >> `helm-org-agenda-files-headings', which prompt you for an org heading, >> then take you there. >> >> I'm always annoyed that, once you're at the heading, it leaves it in >> a half-open state where you can see the immediate text of the target >> entry, but all of its child entries are replaced by an ellipses. >> >> * Target Heading >> Drawers and text >> ... # ellipses instead of child headings >> * Next Heading >> >> You then have to hit twice to see the children. >> >> The helm commands end by calling `org-show-entry', which first does >> this: >> >> (outline-flag-region >> (max (point-min) (1- (point))) >> (save-excursion >>(if (re-search-forward >> (concat "[\r\n]\\(" org-outline-regexp "\\)") nil t) >>(match-beginning 1) >> (point-max))) >> nil) >> >> Which leaves the heading in the state described above, and then does >> this: >> >> (org-cycle-hide-drawers 'children) >> >> Which has no effect. >> >> I'm not really sure what the purpose of `outline-flag-region' is, but >> I'm pretty sure this isn't the desired effect. > > Based on how org-show-entry calls it, outline-flag-region shows the text > from the current heading to the next. So it seems to behave as > documented: "[s]how the body directly following this heading". Okay, but I still don't see how this would ever be the desired result. You can't get to *any* next visibility state without first wasting a . >> The call to `org-cycle-hide-drawers' should reveal children, isn't >> that right? > > The purpose isn't to reveal the child headings (I don't understand why > the argument is called "children"), but to hide the drawers. Weird! But thank you for doing the thinking I was apparently too lazy to do :) [...] >> Which part of this should be tweaked to achieve the desired effect? > > Perhaps helm could call org-show-children after it calls org-show-entry. Okay, cool. I guess my main question was: should this be fixed in helm, or in org? I'll try clobbering the helm functions for a while and see how that goes, then raise this on the helm list. Thanks for your help, Eric
Re: [O] Behavior of `org-show-entry'
Eric Abrahamsenwrites: > I do a lot of my Org navigation with `helm-org-in-buffer-headings' and > `helm-org-agenda-files-headings', which prompt you for an org heading, > then take you there. > > I'm always annoyed that, once you're at the heading, it leaves it in > a half-open state where you can see the immediate text of the target > entry, but all of its child entries are replaced by an ellipses. > > * Target Heading > Drawers and text > ... # ellipses instead of child headings > * Next Heading > > You then have to hit twice to see the children. > > The helm commands end by calling `org-show-entry', which first does > this: > > (outline-flag-region > (max (point-min) (1- (point))) > (save-excursion >(if (re-search-forward > (concat "[\r\n]\\(" org-outline-regexp "\\)") nil t) >(match-beginning 1) > (point-max))) > nil) > > Which leaves the heading in the state described above, and then does > this: > > (org-cycle-hide-drawers 'children) > > Which has no effect. > > I'm not really sure what the purpose of `outline-flag-region' is, but > I'm pretty sure this isn't the desired effect. Based on how org-show-entry calls it, outline-flag-region shows the text from the current heading to the next. So it seems to behave as documented: "[s]how the body directly following this heading". > The call to `org-cycle-hide-drawers' should reveal children, isn't > that right? The purpose isn't to reveal the child headings (I don't understand why the argument is called "children"), but to hide the drawers. Without the org-cycle-hide-drawers call, org-show-entry would expand * TODO blah... to * TODO blah SCHEDULED: <2017-02-12 Sun .+1w> :PROPERTIES: :LAST_REPEAT: [2017-02-05 Sun 16:31] :END: :LOGBOOK: - State "DONE" from "TODO" [2017-02-05 Sun 16:31] :END: instead of * TODO blah SCHEDULED: <2017-02-12 Sun .+1w> :PROPERTIES:... :LOGBOOK:... > Which part of this should be tweaked to achieve the desired effect? Perhaps helm could call org-show-children after it calls org-show-entry. -- Kyle
[O] Behavior of `org-show-entry'
I do a lot of my Org navigation with `helm-org-in-buffer-headings' and `helm-org-agenda-files-headings', which prompt you for an org heading, then take you there. I'm always annoyed that, once you're at the heading, it leaves it in a half-open state where you can see the immediate text of the target entry, but all of its child entries are replaced by an ellipses. * Target Heading Drawers and text ... # ellipses instead of child headings * Next Heading You then have to hit twice to see the children. The helm commands end by calling `org-show-entry', which first does this: (outline-flag-region (max (point-min) (1- (point))) (save-excursion (if (re-search-forward (concat "[\r\n]\\(" org-outline-regexp "\\)") nil t) (match-beginning 1) (point-max))) nil) Which leaves the heading in the state described above, and then does this: (org-cycle-hide-drawers 'children) Which has no effect. I'm not really sure what the purpose of `outline-flag-region' is, but I'm pretty sure this isn't the desired effect. The call to `org-cycle-hide-drawers' should reveal children, isn't that right? Which part of this should be tweaked to achieve the desired effect? Thanks! Eric