[O] [bug ? regression ?] Re: Visibilty of inline tasks

[Marc-Oliver Ihm]

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