Property for startup visibility?

Property for startup visibility?

[Richard KLINDA]

Hello, is there a property for setting the startup visibility (folden,
children or subtree) of a tree?

Thanks,
Richard

Re: Property for startup visibility?

[Peter Jones]

Richard KLINDA <rklinda@gmail.com> writes:
> Hello, is there a property for setting the startup visibility (folden,
> children or subtree) of a tree?

Place this in your .org file.  I keep it near the top:

#+STARTUP: showall

Search the manual for "startup" for more options.

-- 
Peter Jones, pmade inc.
http://pmade.com

Re: Property for startup visibility?

[Richard KLINDA]

>>>>> Regarding 'Re: Property for startup visibility?'; Peter Jones adds:


  > Richard KLINDA <rklinda@gmail.com> writes:
  >> Hello, is there a property for setting the startup visibility
  >> (folden, children or subtree) of a tree?

  > Place this in your .org file.  I keep it near the top:

  > #+STARTUP: showall

  > Search the manual for "startup" for more options.

Thanks, but I would like to set this up on a tree-by-tree basis
(complementing the #+STARTUP option).

For example, currently I have a project file:

,----
| * Task 1
| 
| ** ...
| ** ...
| 
| * Task 2
| 
| ** ..
| ** ..
| 
| * Task 3
|
| ** ..
| ** ..
`----

What I want is setting it up to open like this:

,----
| * Task 1...  (Folded)
| 
| * Task 2     (Content)
| ** ..
| ** ..
| 
| * Task 3...  (Folded)
`----

Does it make sense?  IMHO it could be a nice job for properties.

Richard

Re: Re: Property for startup visibility?

[Carsten Dominik]

On May 7, 2008, at 1:39 PM, Richard KLINDA wrote:

>>>>>> Regarding 'Re: Property for startup visibility?'; Peter Jones  
>>>>>> adds:
>
>
>> Richard KLINDA <rklinda@gmail.com> writes:
>>> Hello, is there a property for setting the startup visibility
>>> (folden, children or subtree) of a tree?
>
>> Place this in your .org file.  I keep it near the top:
>
>> #+STARTUP: showall
>
>> Search the manual for "startup" for more options.
>
> Thanks, but I would like to set this up on a tree-by-tree basis
> (complementing the #+STARTUP option).


Hmmm, I see now what you mean.  I am not convinced how useful this
would be, because I suspect that the visibility you'd like
will often change?

Something like this is easily hacked, see below.  Why don't
you test it a while and then report back with a good example
and use case.  Then we can make a decision about including it.

The following looks for a :visibility: property with value
"folded" or "children" or "all".  Installing it in the hook will run  
it after the global STARTUP visibility has been set.

- Carsten

(defun org-property-visibility ()
   "Switch subtree visibility according to :visibility: property."
   (interactive)
   (let (state)
     (save-excursion
       (goto-char (point-min))
       (while (re-search-forward
	      "^[ \t]*:visibility:[ \t]+\\([a-z]+\\)"
	      nil t)
	(setq state (match-string 1))
	(save-excursion
	  (org-back-to-heading t)
	  (hide-subtree)
	  (org-reveal)
	  (cond
	   ((equal state "children")
	    (org-show-hidden-entry)
	    (show-children))
	   ((equal state "all")
	    (show-subtree)))))
       (org-cycle-hide-drawers 'all))))

(add-hook 'org-mode-hook 'org-property-visibility)

Re: Property for startup visibility?

[bva]

I'll see if I can make this code work for me, too.  Thanks for writing  
it.  I think if I study it carefully, I'll learn something very useful  
about scripting in emacs and in org-mode.  One quick question: if I  
hit C-c C-c on a "Startup" line, does org-mode run the hook again?

As far as a use case is concerned, here's my justification. I have  
wanted to pick certain trees as 'most valuable/visible hierarchies'.   
I do this because my top level structure looks like this:

* Short Term Projects
   :VISIBILITY: Subtree
** TODO Buy Groceries    :OUT:
** TODO Pay gas bill     :HOME:
** PROJECT Fix Sink
*** TODO Buy Tool    :OUT:
*** TODO Buy Supplies :OUT:
*** TODO Fix the sink    :HOME:
*** TODO Check that leak is gone    :HOME:

* Long Term Projects
   :VISIBILITY: CHILDREN
** PROJECT Household Inventory
*** TODO Inventory Bedroom 1   :HOME:
*** TODO Inventory Bedroom 2   :HOME:
*** TODO Inventory Kitchen   :HOME:
*** TODO Inventory Living/Dining Room   :HOME:
** PROJECT Insurance
*** TODO Review coverage      :HOME:
*** TODO Discuss options with advisor   :PHONE:
*** TODO Discuss options with wife    :HOME:

* Maybe/Someday
   :VISIBILITY: FOLDED
** PROJECT RepRap
*** TODO buy parts
*** TODO build device
** PROJECT Solve World Hunger...
** PROJECT Spread World Peace...
** PROJECT Brew my own Weissebier...

* Calendar
   :VISIBILITY: FOLDED
** My trip #1...
** My trip #2...
** Work Holidays...
** Vacation Days...

* Recurring Calendar
   :VISIBILITY: FOLDED
** Club Meeting
<2008-01-01 Mon 20:30-22:00 +1m>
** Dentist
<2008-01-01 Mon +6m>

* Computed Calendar
   :VISIBILITY: FOLDED
** Birthdays of Friends
%%(diary-anniversary  2 10 1869) Mahatma Gandhi would be %d years old
%%(diary-anniversary 1 1 1900) Dad's going to be %d!
*** TODO Buy Dad a ____.  He's got to love it!
    DEADLINE: <2008-12-01 Mon>
** Astronomical Dates
%%(diary-sunrise)
&%%(diary-iso-date)
&%%(diary-day-of-year)

Mostly I want the Short and Long Term projects visible and I'd like to  
hide the calendars.  I like to keep all this in one file because I'm  
most familiar with simple emacs searching, and I'm not yet good at org- 
mode/agenda searches (or global TODO lists, or tag matching, or all  
that)

Since I don't work on "Solve World Hunger" everyday, I find it a  
distraction (as so many people do) to look at the TODOs under that  
project, so a simple TODO tree search hasn't helped me much.  I know  
there is more in org-mode that would fix this, but one of the big  
pleasures of org-mode is how easy (easy, EASY!) it is to get started  
on SOMETHING productive, without having to invest a huge shift in my  
thinking.  (I am working on that shift in thinking, but it has been  
slow to take hold.  Time to re-read the Allen book; maybe this time  
I'll excise some more personal disorganizing demons)

So I'd suggest that the 'VISIBILITY' property does get added.  I'd  
even suggest adding another stop on the org-mode-tab-cycle chain  
(FOLDED VISIBILITY-PROPERTY CHILDREN SUBTREE).  I can even see feature- 
creep with this, as someone may want org-mode to update the VISIBILITY  
property automatically on killing/saving the buffer, so when the file  
is revisited, any hand-tuned folding is recreated.  Thought- 
experiment: Should the VISIBILITY property be automatically inherited?  
Or should we force users to add a property drawer for every tree that  
will be unfolded at my suggested stop on the org-mode-tab-cycle.

It is just a suggestion.  I am very open to other's suggestions of  
better ways of staying on top of my trees.  I'm trying to get to the  
place where every headline has a context tag, a TODO state, a DEADLINE  
or SCHEDULED property (if appropriate) or plain date (if not), AND is  
correctly and logically placed in the existing structure.  I am not  
there yet.

I should add that to my Maybe/Someday tree...

no... my Long Term Project tree!

-Ben

On 2008-05-07 Wed, at 17:00, emacs-orgmode-request@gnu.org wrote:
>
> Message: 1
> Date: Wed, 7 May 2008 17:23:34 +0200
> From: Carsten Dominik <dominik@science.uva.nl>
> Subject: Re: [Orgmode] Re: Property for startup visibility?
> To: Richard KLINDA <rklinda@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Message-ID: <3B5FB20C-6B72-4C69-9374-85FCC2F33173@science.uva.nl>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On May 7, 2008, at 1:39 PM, Richard KLINDA wrote:
>>
>>
>> Thanks, but I would like to set this up on a tree-by-tree basis
>> (complementing the #+STARTUP option).
>
>
> Hmmm, I see now what you mean.  I am not convinced how useful this
> would be, because I suspect that the visibility you'd like
> will often change?
>
> Something like this is easily hacked, see below.  Why don't
> you test it a while and then report back with a good example
> and use case.  Then we can make a decision about including it.
>
> The following looks for a :visibility: property with value
> "folded" or "children" or "all".  Installing it in the hook will run
> it after the global STARTUP visibility has been set.
>
> - Carsten

Re: Property for startup visibility?

[Carsten Dominik]

Hi Ben,

On May 7, 2008, at 8:29 PM, bva@alexanderonline.org wrote:

> Mostly I want the Short and Long Term projects visible and I'd like  
> to hide the calendars.  I like to keep all this in one file because  
> I'm most familiar with simple emacs searching, and I'm not yet good  
> at org-mode/agenda searches (or global TODO lists, or tag matching,  
> or all that)

I am starting to like the idea.

> Since I don't work on "Solve World Hunger" everyday, I find it a  
> distraction (as so many people do) to look at the TODOs under that  
> project, so a simple TODO tree search hasn't helped me much.  I know  
> there is more in org-mode that would fix this, but one of the big  
> pleasures of org-mode is how easy (easy, EASY!) it is to get started  
> on SOMETHING productive, without having to invest a huge shift in my  
> thinking.  (I am working on that shift in thinking, but it has been  
> slow to take hold.  Time to re-read the Allen book; maybe this time  
> I'll excise some more personal disorganizing demons)
>
> So I'd suggest that the 'VISIBILITY' property does get added.  I'd  
> even suggest adding another stop on the org-mode-tab-cycle chain  
> (FOLDED VISIBILITY-PROPERTY CHILDREN SUBTREE).

Definitely not.  Visibility cycling works because there is a clear  
sequence in it from showing little to showing everything.  Such an  
extra stop would kill intuition, I believe.  Instead, I could make a  
command, say `C-u C-u TAB' to switch back the entire buffer to the  
startup visibility.  And by the way, during C-c C-c on an option, org- 
mode-hook is not run again.

> I can even see feature-creep with this, as someone may want org-mode  
> to update the VISIBILITY property automatically on killing/saving  
> the buffer, so when the file is revisited, any hand-tuned folding is  
> recreated.

That has been requested before, but storing the visibility permanently  
in properties sound like overkill to me.  So no for now.


> Thought-experiment: Should the VISIBILITY property be automatically  
> inherited?

I dont think so.  Better to make possible values for the visibility  
that affect the entire tree below.  For example:

folded
children  (like the local "children" state)
content   (like the global "content" state, but local tree only
all

- Carsten

Re: Property for startup visibility?

[Carsten Dominik]

On May 8, 2008, at 2:03 PM, Carsten Dominik wrote:

>
>> Thought-experiment: Should the VISIBILITY property be automatically  
>> inherited?
>
> I dont think so.  Better to make possible values for the visibility  
> that affect the entire tree below.  For example:
>
> folded
> children  (like the local "children" state)
> content   (like the global "content" state, but local tree only
> all

This is what I have implemented now:  Allowed values for the  
visibility property:

folded
children
content
all

And a new command `C-u C-u TAB' which means, go back to startup  
visibility.

Thanks for the suggestion.

- Carsten

Re: Property for startup visibility?

[bva]

On 2008-05-08 Thu, at 13:03, Carsten Dominik wrote:

>
> I am starting to like the idea.
>
>>

Wow, I've never felt so .... convincing before!

>> Thought-experiment: Should the VISIBILITY property be automatically  
>> inherited?
>
> I dont think so.  Better to make possible values for the visibility  
> that affect the entire tree below.  For example:
>
> folded
> children  (like the local "children" state)
> content   (like the global "content" state, but local tree only
> all
>
Yeah, that is clearly a much better idea.

To continue with that thought, may I suggest an additional value of  
'invisible'?

	invisible: this headline (and content) is folded into the preceding  
headline
	folded: this headline is visible, but the content under it is invisible

Perhaps there is better term for this. (What are those ellipses called  
now?) I would use 'invisible' for:
  1. calendar headlines in the recent past. Right now I use  
the :ARCHIVE: tag to prevent unfolding, but in after I sort in  
chronological order, I still get too many old things showing up at the  
top of the tree.  The down side is that then these items disappear  
from my agenda, where I sometimes scroll backwards to see what I did  
on that day.

  2. projects that are completed but not yet archived (for me,  
everything, as I haven't really gotten comfortable with moving  
subtrees around using the archive mechanism)

  3. reference headlines (phone number or booking confirmation  
numbers) that I don't need when planning, only while doing

I see myself going to my preset visibility (C-u C-u TAB) and looking  
at my tree in one window.  This would complement the agenda view,  
where doing something may require that phone number, and I have to hit  
TAB and get a split window.


Please don't hold this suggestion against having a visibility  
property ;-)

Next thought experiment: I suppose you'll have an immediate reaction  
on whether a descendant's  visibility setting should override the  
ancestor's or vice versa.

If I bury a task inside a calendar item (like my dad's birthday  
present in my original email), is it going to get shown (yeah!  
descendant's setting!) or not (boo!).

Alternatively if I've set a Project headline (always a 2nd level  
headline in my original file) to ':VISIBILITY: children' but then try  
to set ':VISIBILITY: folded' at the top level head while I focus on  
something other area of the file, am I going to see the Project and  
its children (boo!) or will it be invisibly merged into the ellipses  
of the ancestor? (Yeah! ancestor's setting!)

Having just written that, my vote is #1.  If I need to focus on  
something for the time being, I'll just use tab.  It'll always ignore  
the visibility property (curses!) ;-)

Hypothetically speaking.

-Ben