* Visibilty of inline tasks @ 2010-12-16 13:26 Sébastien Vauban 2012-02-06 19:23 ` Marc-Oliver Ihm 0 siblings, 1 reply; 4+ messages in thread From: Sébastien Vauban @ 2010-12-16 13:26 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hello, Though that is written in =org-inlinetask.el=: ;; Visibility cycling exempts these nodes from cycling. So whenever their ;; parent is opened, so are these tasks. I have the impression that, up to a couple of days ago, the inlined headlines were showed in the =children= view, such as: --8<---------------cut here---------------start------------->8--- * TODO Write document ** TODO Write intro ** TODO Write code *************** WAIT Ask the client about specs ** TODO Write conclusion --8<---------------cut here---------------end--------------->8--- Am I right? - If yes, could it be back like that? - If no, would others as well be interested in such a behavior? Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Visibilty of inline tasks 2010-12-16 13:26 Visibilty of inline tasks Sébastien Vauban @ 2012-02-06 19:23 ` Marc-Oliver Ihm 2012-02-06 20:34 ` Sebastien Vauban 0 siblings, 1 reply; 4+ messages in thread From: Marc-Oliver Ihm @ 2012-02-06 19:23 UTC (permalink / raw) To: emacs-orgmode; +Cc: public-emacs-orgmode-mXXj517/zsQ Am 16.12.2010 14:26, schrieb Sébastien Vauban: > Hello, > > Though that is written in =org-inlinetask.el=: > > ;; Visibility cycling exempts these nodes from cycling. So whenever their > ;; parent is opened, so are these tasks. > > I have the impression that, up to a couple of days ago, the inlined headlines > were showed in the =children= view, such as: > > --8<---------------cut here---------------start------------->8--- > * TODO Write document > ** TODO Write intro > ** TODO Write code > *************** WAIT Ask the client about specs > ** TODO Write conclusion > --8<---------------cut here---------------end--------------->8--- > > Am I right? > > - If yes, could it be back like that? > - If no, would others as well be interested in such a behavior? > > Best regards, > Seb > Hello all, as far as I can see, Sebastien description still applies. This behaviour (bug ?) makes it hard to work with inline-tasks (which I do alot), because once I open the topmost node, all subheadings with any inline task are opened too, regardless how depp they are nested. This makes it nearly impossible to get an overview about the contents of the node. So: This problem still seems to be around. with kind regards, Marc-Oliver Ihm (And sorry for not beeing able to see the immediate elisp-cause of the problem !) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Visibilty of inline tasks 2012-02-06 19:23 ` Marc-Oliver Ihm @ 2012-02-06 20:34 ` Sebastien Vauban 2012-02-08 21:06 ` [bug ? regression ?] " Marc-Oliver Ihm 0 siblings, 1 reply; 4+ messages in thread From: Sebastien Vauban @ 2012-02-06 20:34 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hi Marc-Oliver, Marc-Oliver Ihm wrote: > Am 16.12.2010 14:26, schrieb Sébastien Vauban: >> Though that is written in =org-inlinetask.el=: >> >> ;; Visibility cycling exempts these nodes from cycling. So whenever their >> ;; parent is opened, so are these tasks. >> >> I have the impression that, up to a couple of days ago, the inlined headlines >> were showed in the =children= view, such as: >> >> --8<---------------cut here---------------start------------->8--- >> * TODO Write document >> ** TODO Write intro >> ** TODO Write code >> *************** WAIT Ask the client about specs >> ** TODO Write conclusion >> --8<---------------cut here---------------end--------------->8--- >> >> Am I right? >> >> - If yes, could it be back like that? >> - If no, would others as well be interested in such a behavior? > > as far as I can see, Sebastien description still applies. This behaviour > (bug ?) makes it hard to work with inline-tasks (which I do alot), because > once I open the topmost node, all subheadings with any inline task are > opened too, regardless how depp they are nested. This makes it nearly > impossible to get an overview about the contents of the node. > > So: This problem still seems to be around. What I described was the impression that: - before December, inline tasks were shown when TAB'ing - at some point in December, they were not anymore. That's wrong. And I had mixed impressions because I saw them when C-c / t'ing for tasks inside a document. In fact, I share your point of view: as they don't participate to document structure (that's why they're inline tasks), they should not be made visible when cycling. That's not the current behavior. Best regards, Seb -- Sebastien Vauban ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bug ? regression ?] Re: Visibilty of inline tasks 2012-02-06 20:34 ` Sebastien Vauban @ 2012-02-08 21:06 ` Marc-Oliver Ihm 0 siblings, 0 replies; 4+ messages in thread From: Marc-Oliver Ihm @ 2012-02-08 21:06 UTC (permalink / raw) To: emacs-orgmode; +Cc: public-emacs-orgmode-mXXj517/zsQ Hi Seb, I tried an example: * 1 ** 2 ** 3 *************** 4 *************** END This tree works as expected: If it is completly folded and you press TAB on the heading "* 1", you get this: * 1 ** 2 ** 3... which is, what can be expeced and what is described in the documenatation. However, things are different, if you modify the tree by adding an inlinetask RIGHT BELOW the firstlevel headline: * 1 *************** 5 *************** END ** 2 ** 3 *************** 4 *************** END If this tree is completely folded and you press TAB on the heading, EVERYTHING gets unfolded (which looks exactly as above of course). This is not what I would expect and in LARGER TREES this makes it impossible to get an OVERVIEW. (sorry for the free overuse of emphasis here ...) However, this problem only applies to the latest version of orgmode (7.8); in older Versions (e.g. 7.4, which I had lying around too :-) you get this screen after pressing TAB once: * 1 *************** 5 *************** END ** 2 ** 3... which is quite nice and hides the Inlinetask "5". So: As you expected: There has been a state of good behaviour, which we only need to restore :-) Moreover I tried to venture into the code and found, that cycling is probably done in org-cycle-internal-local, which in turn calls show-children from the old outline-package. Reading its docstring says: > Show all direct subheadings of this heading. > Prefix arg LEVEL is how many levels below the current level should be shown. > Default is enough to cause the following heading to appear. and this explains the unpleasant behaviour shown above: If the first level below the current level is an inlinetask, this will probably cause EVERY heading within the tree to be shown. Okay. Lets summarize: Probably we understood whats happening, and it might be possible to fix this (because it worked not long ago in Version 7.4). Unfortunately I am not sure, if my lisp-capabilities are strong enough to fix this (are yours ?). But probably I will try over the weekend anyway if nobody else volunteers ... Afterwards, we either have a patch to test or need to declare bankruptcy and ask for help of a real elisp-wizard :-) with kind regards, Marc Am 06.02.2012 21:34, schrieb Sebastien Vauban: > Hi Marc-Oliver, > > Marc-Oliver Ihm wrote: >> Am 16.12.2010 14:26, schrieb Sébastien Vauban: >>> Though that is written in =org-inlinetask.el=: >>> >>> ;; Visibility cycling exempts these nodes from cycling. So whenever their >>> ;; parent is opened, so are these tasks. >>> >>> I have the impression that, up to a couple of days ago, the inlined headlines >>> were showed in the =children= view, such as: >>> >>> --8<---------------cut here---------------start------------->8--- >>> * TODO Write document >>> ** TODO Write intro >>> ** TODO Write code >>> *************** WAIT Ask the client about specs >>> ** TODO Write conclusion >>> --8<---------------cut here---------------end--------------->8--- >>> >>> Am I right? >>> >>> - If yes, could it be back like that? >>> - If no, would others as well be interested in such a behavior? >> >> as far as I can see, Sebastien description still applies. This behaviour >> (bug ?) makes it hard to work with inline-tasks (which I do alot), because >> once I open the topmost node, all subheadings with any inline task are >> opened too, regardless how depp they are nested. This makes it nearly >> impossible to get an overview about the contents of the node. >> >> So: This problem still seems to be around. > > What I described was the impression that: > > - before December, inline tasks were shown when TAB'ing > - at some point in December, they were not anymore. That's wrong. And I had > mixed impressions because I saw them when C-c / t'ing for tasks inside a > document. > > In fact, I share your point of view: as they don't participate to document > structure (that's why they're inline tasks), they should not be made visible > when cycling. That's not the current behavior. > > Best regards, > Seb > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-02-08 21:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-12-16 13:26 Visibilty of inline tasks Sébastien Vauban 2012-02-06 19:23 ` Marc-Oliver Ihm 2012-02-06 20:34 ` Sebastien Vauban 2012-02-08 21:06 ` [bug ? regression ?] " Marc-Oliver Ihm
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).