* 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).