* Two issues with :VISIBILITY: property
@ 2010-11-29 16:04 Cassio Koshikumo
2010-12-06 4:41 ` Matt Lundin
2010-12-06 4:45 ` [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties" Matt Lundin
0 siblings, 2 replies; 8+ messages in thread
From: Cassio Koshikumo @ 2010-11-29 16:04 UTC (permalink / raw)
To: emacs-orgmode
Hi all,
I've just recently began using emacs and org-mode, and I'm already in
love. So, first, let me thank and congratulate Mr. Dominik and
everyone else involved.
Now, I have two questions about the :VISIBILITY: property. (I did find
some info on the archives but, unless I misinterpreted it, I think
this is a different matter.)
What I want to do, basically, is to replicate a cool functionality
from Scrivener, a Mac app for writing long documents. Scrivener can
associate a synopsis with each chunk of text, allowing you to
reorganize the structure based on the synopsis. Org-mode seems
perfectly capable of doing that using the following setup:
* Chapter 1
:PROPERTIES:
:VISIBILITY: children
:END:
The synopses for chapter 1 goes here.
** Section 1 (Ch.1)
The actual text for Section 1 of Chapter 1.
** Section 2 (Ch.1)
The actual text for Section 2 of Chapter 1.
And so on.
The "children" property allows me to press C-u C-u <TAB> to show only
the synopsis and the headlines inside the chapters -- which is exactly
what I want.
But here's the thing: if I decide to put "Chapter 1" /after/ "Chapter
2", using M-Down or M-S-Down, it gets moved alright -- but the entire
Chapter 1 subtree is expanded. I no longer see only the headlines
inside it, but also the entire text inside them. Is this by design? If
so, why? It seems to me that the :VISIBILITY: property should hold
when moving trees around.
That was the first issue. The second is:
The :VISIBILITY: property seems to work only when it's applied to
level 1 trees. For example, say I have this:
* Part 1
** Chapter 1
:PROPERTIES:
:VISIBILITY: children
:END:
Synopsis for Chapter 1 goes here.
*** Section 1 (Ch.1)
The actual text for Section 1 of Chapter 1.
** Chapter 2
:PROPERTIES:
:VISIBILITY: children
:END:
Synopsis for Chapter 2 goes here.
*** Section 1 (Ch.2)
The actual text for Section 1 of Chapter 2.
When I press C-u C-u <TAB>, only Chapter 1 gets expanded correctly
(synopsis + headlines inside it). Chapter 2 stays completely folded
("Chapter 2..."), without any children or content shown -- effectively
ignoring the "children" property, or acting as it was set to "folded".
I guess this wasn't supposed to happen, right?
Any help on these matters would be much appreciated. Also, if anyone
knows of a better way to accomplish what I'm trying to do, please tell
me. I experimented with a :SYNOPSIS: drawer, but it didn't seem
adequate. There's no way of showing only the drawer and hiding
everything else (which makes sense, since the drawers were made to
hide content, so I'm not saying this should be an option).
I'm using yesterday's snapshot from the repository, so I'm pretty much
up to date. Emacs 23.2 on a Mac OS X 10.6.5.
Thanks,
--
Cássio Koshikumo
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Two issues with :VISIBILITY: property
2010-11-29 16:04 Two issues with :VISIBILITY: property Cassio Koshikumo
@ 2010-12-06 4:41 ` Matt Lundin
2010-12-07 0:12 ` Cassio Koshikumo
2010-12-06 4:45 ` [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties" Matt Lundin
1 sibling, 1 reply; 8+ messages in thread
From: Matt Lundin @ 2010-12-06 4:41 UTC (permalink / raw)
To: Cassio Koshikumo; +Cc: emacs-orgmode, Carsten Dominik
Cassio Koshikumo <ckoshikumo@gmail.com> writes:
> I've just recently began using emacs and org-mode, and I'm already in
> love. So, first, let me thank and congratulate Mr. Dominik and
> everyone else involved.
Welcome!
> The "children" property allows me to press C-u C-u <TAB> to show only
> the synopsis and the headlines inside the chapters -- which is exactly
> what I want.
>
> But here's the thing: if I decide to put "Chapter 1" /after/ "Chapter
> 2", using M-Down or M-S-Down, it gets moved alright -- but the entire
> Chapter 1 subtree is expanded. I no longer see only the headlines
> inside it, but also the entire text inside them. Is this by design? If
> so, why? It seems to me that the :VISIBILITY: property should hold
> when moving trees around.
I cannot replicate this. When I move the headlines, they remain folded.
> That was the first issue. The second is:
>
> The :VISIBILITY: property seems to work only when it's applied to
> level 1 trees. For example, say I have this:
>
> * Part 1
>
> ** Chapter 1
> :PROPERTIES:
> :VISIBILITY: children
> :END:
>
> Synopsis for Chapter 1 goes here.
>
> *** Section 1 (Ch.1)
> The actual text for Section 1 of Chapter 1.
>
> ** Chapter 2
> :PROPERTIES:
> :VISIBILITY: children
> :END:
>
> Synopsis for Chapter 2 goes here.
>
> *** Section 1 (Ch.2)
> The actual text for Section 1 of Chapter 2.
>
> When I press C-u C-u <TAB>, only Chapter 1 gets expanded correctly
> (synopsis + headlines inside it). Chapter 2 stays completely folded
> ("Chapter 2..."), without any children or content shown -- effectively
> ignoring the "children" property, or acting as it was set to "folded".
> I guess this wasn't supposed to happen, right?
Yes, this is a bug. Thanks for reporting it.
It was introduced with commit 383802d063a9f2dd959d5574b226fa8ec7f8be41,
which caused the problem it intended to solve. See:
http://thread.gmane.org/gmane.emacs.orgmode/28159/focus=28442
The commit has org-mode process the headlines from bottom to top, which
means that any changes to the visibility of lower headlines are
overridden/modified by changes higher up. Reverting the change causes
VISIBILITY to work correctly.
I send a patch shortly.
Thanks,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Two issues with :VISIBILITY: property
2010-12-06 4:41 ` Matt Lundin
@ 2010-12-07 0:12 ` Cassio Koshikumo
2010-12-07 11:30 ` Matt Lundin
2010-12-09 9:49 ` Carsten Dominik
0 siblings, 2 replies; 8+ messages in thread
From: Cassio Koshikumo @ 2010-12-07 0:12 UTC (permalink / raw)
To: Matt Lundin; +Cc: emacs-orgmode
Thanks a lot, Matt! The patch did correct the second issue.
About the first one:
> I cannot replicate this. When I move the headlines, they remain folded.
It's strange that you cannot replicate this behavior. I got today's
snapshot and disabled all my customizations to try a vanilla install,
and it's still there.
Just to make sure we're talking about the same thing: when you move
the Level 1 tree (the one that has the PROPERTY drawer) it really
keeps folded? I ask because I noticed that, if I move one of its
children, everything remains folded. But if I move the parent tree,
the entire tree gets expanded.
By the way, it doesn't even take a VISIBILITY setting to cause this. Say I have:
* Chapter 1
Text under Chapter 1.
** Section A
Text under Section A.
* Chapter 2
Text under Chapter 2.
** Section B
Text under Section B.
Using S-TAB, I go to OVERVIEW:
* Chapter 1...
* Chapter 2...
Now I place the cursor on "Chapter 1" and press TAB:
* Chapter 1
Text under Chapter 1.
** Section A...
* Chapter 2...
Right now, "Section A" remains folded, which is what you'd expect
(because "Chapter 1" is only showing its children). But, if I move
"Chapter 1" down, putting it after "Chapter 2", "Section A" gets
expanded:
* Chapter 2...
* Chapter 1
Text under Chapter 1.
** Section A
Text under Section A.
This behavior is absolutely consistent here... If you really cannot
replicate it, I wonder what could be causing it in my installation.
Thanks again for your help and time,
--
Cássio Koshikumo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Two issues with :VISIBILITY: property
2010-12-07 0:12 ` Cassio Koshikumo
@ 2010-12-07 11:30 ` Matt Lundin
2010-12-09 9:49 ` Carsten Dominik
1 sibling, 0 replies; 8+ messages in thread
From: Matt Lundin @ 2010-12-07 11:30 UTC (permalink / raw)
To: Cassio Koshikumo; +Cc: emacs-orgmode
Cassio Koshikumo <ckoshikumo@gmail.com> writes:
> Thanks a lot, Matt! The patch did correct the second issue.
>
> About the first one:
>
>> I cannot replicate this. When I move the headlines, they remain folded.
>
> It's strange that you cannot replicate this behavior. I got today's
> snapshot and disabled all my customizations to try a vanilla install,
> and it's still there.
>
> Just to make sure we're talking about the same thing: when you move
> the Level 1 tree (the one that has the PROPERTY drawer) it really
> keeps folded? I ask because I noticed that, if I move one of its
> children, everything remains folded. But if I move the parent tree,
> the entire tree gets expanded.
>
> By the way, it doesn't even take a VISIBILITY setting to cause this. Say I have:
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A
> Text under Section A.
>
> * Chapter 2
> Text under Chapter 2.
>
> ** Section B
> Text under Section B.
>
> Using S-TAB, I go to OVERVIEW:
>
> * Chapter 1...
> * Chapter 2...
>
> Now I place the cursor on "Chapter 1" and press TAB:
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A...
>
> * Chapter 2...
>
> Right now, "Section A" remains folded, which is what you'd expect
> (because "Chapter 1" is only showing its children). But, if I move
> "Chapter 1" down, putting it after "Chapter 2", "Section A" gets
> expanded:
>
> * Chapter 2...
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A
> Text under Section A.
>
> This behavior is absolutely consistent here... If you really cannot
> replicate it, I wonder what could be causing it in my installation.
You are right. I can replicate this now, following the steps above. I'm
not sure whether this is the intended behavior or not. Perhaps someone
who understands the code better than I do can chime in....
Best,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Two issues with :VISIBILITY: property
2010-12-07 0:12 ` Cassio Koshikumo
2010-12-07 11:30 ` Matt Lundin
@ 2010-12-09 9:49 ` Carsten Dominik
2010-12-11 3:55 ` Cassio Koshikumo
1 sibling, 1 reply; 8+ messages in thread
From: Carsten Dominik @ 2010-12-09 9:49 UTC (permalink / raw)
To: Cassio Koshikumo; +Cc: Matt Lundin, emacs-orgmode
Hi Cassio,
while I agree that it would be nice to keep the detailed
visibility structure of a tree while moving it, the effort
to implement that is rather large.
Org moves the tree by cutting it out and pasting it back in.
Outline visibility is done using overlays, not text properties.
Overlays are lost when cutting and pasting text.
So what one would have to do is save all the overlays, compute
their relative distance to the tree head, and re-install
them after pasting. Possible, but an unproportional
effort in my view.
Org settles currently for this:
When a tree is folded entirely, it will be folded after it has
been moved. When it is not folded entirely, then it will
remain unfolded after the pasting.
I think that this is entirely acceptable, so I don't view
it as a bug. Desirable - maybe yes, but not
important in my view.
- Carsten
On Dec 7, 2010, at 1:12 AM, Cassio Koshikumo wrote:
> Thanks a lot, Matt! The patch did correct the second issue.
>
> About the first one:
>
>> I cannot replicate this. When I move the headlines, they remain
>> folded.
>
> It's strange that you cannot replicate this behavior. I got today's
> snapshot and disabled all my customizations to try a vanilla install,
> and it's still there.
>
> Just to make sure we're talking about the same thing: when you move
> the Level 1 tree (the one that has the PROPERTY drawer) it really
> keeps folded? I ask because I noticed that, if I move one of its
> children, everything remains folded. But if I move the parent tree,
> the entire tree gets expanded.
>
> By the way, it doesn't even take a VISIBILITY setting to cause this.
> Say I have:
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A
> Text under Section A.
>
> * Chapter 2
> Text under Chapter 2.
>
> ** Section B
> Text under Section B.
>
> Using S-TAB, I go to OVERVIEW:
>
> * Chapter 1...
> * Chapter 2...
>
> Now I place the cursor on "Chapter 1" and press TAB:
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A...
>
> * Chapter 2...
>
> Right now, "Section A" remains folded, which is what you'd expect
> (because "Chapter 1" is only showing its children). But, if I move
> "Chapter 1" down, putting it after "Chapter 2", "Section A" gets
> expanded:
>
> * Chapter 2...
>
> * Chapter 1
> Text under Chapter 1.
>
> ** Section A
> Text under Section A.
>
> This behavior is absolutely consistent here... If you really cannot
> replicate it, I wonder what could be causing it in my installation.
>
> Thanks again for your help and time,
>
> --
> Cássio Koshikumo
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Two issues with :VISIBILITY: property
2010-12-09 9:49 ` Carsten Dominik
@ 2010-12-11 3:55 ` Cassio Koshikumo
0 siblings, 0 replies; 8+ messages in thread
From: Cassio Koshikumo @ 2010-12-11 3:55 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Matt Lundin, emacs-orgmode
Hi, Carsten,
I understand what you're saying. I've been looking at the functions
responsible for moving trees around and still can't get my head around
them. Not that this means much, as I'm just starting to dabble in some
elisp and don't have lots of experience with other languages either,
but I still see it would require a lot of work.
Let's see. If I manage to get a better hold of elisp, maybe I'll try
to make a patch. For now, those parenthesis still make my eyes
cross...
Thanks,
2010/12/9 Carsten Dominik <carsten.dominik@gmail.com>:
> Hi Cassio,
>
> while I agree that it would be nice to keep the detailed
> visibility structure of a tree while moving it, the effort
> to implement that is rather large.
>
> Org moves the tree by cutting it out and pasting it back in.
>
> Outline visibility is done using overlays, not text properties.
> Overlays are lost when cutting and pasting text.
>
> So what one would have to do is save all the overlays, compute
> their relative distance to the tree head, and re-install
> them after pasting. Possible, but an unproportional
> effort in my view.
>
> Org settles currently for this:
>
> When a tree is folded entirely, it will be folded after it has
> been moved. When it is not folded entirely, then it will
> remain unfolded after the pasting.
>
> I think that this is entirely acceptable, so I don't view
> it as a bug. Desirable - maybe yes, but not
> important in my view.
>
> - Carsten
>
> On Dec 7, 2010, at 1:12 AM, Cassio Koshikumo wrote:
>
>> Thanks a lot, Matt! The patch did correct the second issue.
>>
>> About the first one:
>>
>>> I cannot replicate this. When I move the headlines, they remain folded.
>>
>> It's strange that you cannot replicate this behavior. I got today's
>> snapshot and disabled all my customizations to try a vanilla install,
>> and it's still there.
>>
>> Just to make sure we're talking about the same thing: when you move
>> the Level 1 tree (the one that has the PROPERTY drawer) it really
>> keeps folded? I ask because I noticed that, if I move one of its
>> children, everything remains folded. But if I move the parent tree,
>> the entire tree gets expanded.
>>
>> By the way, it doesn't even take a VISIBILITY setting to cause this. Say I
>> have:
>>
>> * Chapter 1
>> Text under Chapter 1.
>>
>> ** Section A
>> Text under Section A.
>>
>> * Chapter 2
>> Text under Chapter 2.
>>
>> ** Section B
>> Text under Section B.
>>
>> Using S-TAB, I go to OVERVIEW:
>>
>> * Chapter 1...
>> * Chapter 2...
>>
>> Now I place the cursor on "Chapter 1" and press TAB:
>>
>> * Chapter 1
>> Text under Chapter 1.
>>
>> ** Section A...
>>
>> * Chapter 2...
>>
>> Right now, "Section A" remains folded, which is what you'd expect
>> (because "Chapter 1" is only showing its children). But, if I move
>> "Chapter 1" down, putting it after "Chapter 2", "Section A" gets
>> expanded:
>>
>> * Chapter 2...
>>
>> * Chapter 1
>> Text under Chapter 1.
>>
>> ** Section A
>> Text under Section A.
>>
>> This behavior is absolutely consistent here... If you really cannot
>> replicate it, I wonder what could be causing it in my installation.
>>
>> Thanks again for your help and time,
>>
>> --
>> Cássio Koshikumo
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
--
Cássio Koshikumo
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties"
2010-11-29 16:04 Two issues with :VISIBILITY: property Cassio Koshikumo
2010-12-06 4:41 ` Matt Lundin
@ 2010-12-06 4:45 ` Matt Lundin
2010-12-06 9:07 ` Carsten Dominik
1 sibling, 1 reply; 8+ messages in thread
From: Matt Lundin @ 2010-12-06 4:45 UTC (permalink / raw)
To: Org Mode
This reverts commit 383802d063a9f2dd959d5574b226fa8ec7f8be41.
The commit had org-mode process the headlines from bottom to top, which
meant that any changes to the visibility of lower headlines were
overridden/modified by changes higher up the tree. Reverting the commit
causes VISIBILITY to work correctly.
---
lisp/org.el | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 66514a2..4b39c9c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6073,8 +6073,8 @@ With a numeric prefix, show all headlines up to that level."
(interactive)
(let (org-show-entry-below state)
(save-excursion
- (goto-char (point-max))
- (while (re-search-backward
+ (goto-char (point-min))
+ (while (re-search-forward
"^[ \t]*:VISIBILITY:[ \t]+\\([a-z]+\\)"
nil t)
(setq state (match-string 1))
--
1.7.3.2
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties"
2010-12-06 4:45 ` [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties" Matt Lundin
@ 2010-12-06 9:07 ` Carsten Dominik
0 siblings, 0 replies; 8+ messages in thread
From: Carsten Dominik @ 2010-12-06 9:07 UTC (permalink / raw)
To: Matt Lundin; +Cc: Org Mode
Applied, thanks.
- Carsten
On Dec 6, 2010, at 5:45 AM, Matt Lundin wrote:
> This reverts commit 383802d063a9f2dd959d5574b226fa8ec7f8be41.
>
> The commit had org-mode process the headlines from bottom to top,
> which
> meant that any changes to the visibility of lower headlines were
> overridden/modified by changes higher up the tree. Reverting the
> commit
> causes VISIBILITY to work correctly.
> ---
> lisp/org.el | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 66514a2..4b39c9c 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -6073,8 +6073,8 @@ With a numeric prefix, show all headlines up
> to that level."
> (interactive)
> (let (org-show-entry-below state)
> (save-excursion
> - (goto-char (point-max))
> - (while (re-search-backward
> + (goto-char (point-min))
> + (while (re-search-forward
> "^[ \t]*:VISIBILITY:[ \t]+\\([a-z]+\\)"
> nil t)
> (setq state (match-string 1))
> --
> 1.7.3.2
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- Carsten
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-12-11 3:56 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-29 16:04 Two issues with :VISIBILITY: property Cassio Koshikumo
2010-12-06 4:41 ` Matt Lundin
2010-12-07 0:12 ` Cassio Koshikumo
2010-12-07 11:30 ` Matt Lundin
2010-12-09 9:49 ` Carsten Dominik
2010-12-11 3:55 ` Cassio Koshikumo
2010-12-06 4:45 ` [PATCH] Revert "Fix :VISIBILITY: handling of nested "folded" properties" Matt Lundin
2010-12-06 9:07 ` Carsten Dominik
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).