Re: Bug or expected behavior? org-sparse-tree visibility toggling
Hm. It makes sense that TAB is not affected... Somehow I hadn't really considered that. What I expected to happen (and now I realize it was not a justified expectation) was to have the visibility of the sparse-tree kept while tabbing. So I could expand a tree, then collapse it again, all the while keeping the sparse-tree "filter" applied. But I guess it doesn't make much sense. Well, I guess I could leave it as a suggestion for new functionality, but I don't even know if it's feasible. Thanks! On Sun, Feb 26, 2023 at 8:52 AM Ihor Radchenko wrote: > > Cassio Koshikumo writes: > > > Create an .org file with the following contents: > > > > * First Level > > ... > > Now, C-c / m (or M-x org-sparse-tree and select m) and Match: tag. > > > > The resulting sparse tree looks like this: > > > > * First Level > > ** One :tag: > > *** Child > > ** Four :tag: > > > > So far, so good. Now, put point on heading One and press TAB. Child is > > hidden. > > > > The problem: press TAB again. Now Two and Three are also shown, > > effectively breaking the sparse tree filtering. (Actually Five is > > shown, too, it seems...) > > is not affected by sparse tree. > Sparse tree just reveals headings that match certain criteria and > highlights them. > > May you describe what you expected to happen? > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> -- Cassio Koshikumo
Bug or expected behavior? org-sparse-tree visibility toggling
I don't know if this can be considered a bug or if I'm trying to do something not supported. Create an .org file with the following contents: * First Level ** One :tag: *** Child ** Two ** Three ** Four :tag: ** Five Now, C-c / m (or M-x org-sparse-tree and select m) and Match: tag. The resulting sparse tree looks like this: * First Level ** One :tag: *** Child ** Four :tag: So far, so good. Now, put point on heading One and press TAB. Child is hidden. The problem: press TAB again. Now Two and Three are also shown, effectively breaking the sparse tree filtering. (Actually Five is shown, too, it seems...) As far as I can tell, this only happens when the heading has a subheading, like Child. But even when dealing with headings that DON'T have a subheading, the ellipsis kinda breaks and ends up in the next line, and successive TABs do nothing. (In fact, I was trying different variations of the tree just now and it seems the behavior is WILDLY inconsistent. If there's a blank line between One and Child, then the first TABalready messes the tree up. Don't know if further variations produce other results.) So, can these behaviors be considered bugs? Or are sparse trees not meant to have their visibility manipulated like this, and should be considered a static, filtered view of the tree, with interactions discouraged? Thanks! -- Cassio Koshikumo
Re: [BUG] Creating sparse tree with regexp property matches
Hey, great! I was going to patch the example (was just reading the commit guidelines) but I'll leave it in your hands then. Thanks! Best, On Tue, Aug 31, 2021 at 9:33 AM Daniel Fleischer wrote: > > Timothy [2021-08-31 Tue 19:27] wrote: > > > Hi Cassio, > > > >> Ah! Can’t believe I didn’t try that. Well, at least the docs can > >> benefit from my confusion. > > > > Would you be interested in making a patch for the docs, or would you rather > > leave that to someone else? > > Actually I want to do that. I had an idea to add a node (in org) > "reminding" people that all mentions of regex refer to elisp regex, > which could be different than what people usually know (PCRE) and point > them toward the elisp regex node. I think this point can confuse non > technical people when they are starting to use orgmode and there should > be a mention in the org manual. Most notably are the alternation \| > instead of | and \(...\) grouping instead of (...). > > Best, > > > *Daniel Fleischer* -- Cassio Koshikumo
Re: [BUG] Creating sparse tree with regexp property matches
Ah! Can't believe I didn't try that. Well, at least the docs can
benefit from my confusion.
Thanks,
On Wed, Aug 25, 2021 at 6:05 PM Daniel Fleischer wrote:
>
> On Wed, Aug 25 2021, Cassio Koshikumo wrote:
> > Hello all,
> >
> > I think there's a bug with `org-make-tags-matcher' when creating a sparse
> > tree
> > using property matching with regular expressions and "or" terms. Take the
> > example given in the manual:
> >
> > +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
> >+With={Sarah|Denny}+SCHEDULED>="<2008-10-11 Sat>"
> >
> > If we isolate just this part:
> >
> > +With={Sarah|Denny}
> >
> > The resulting sparse tree does not match the right
> > headings. The function generates the following `tagsmatcher':
> >
> > (progn
> > (setq org-cached-props nil)
> > (or
> >(and
> > (member
> > #("Denny" 0 5
> >(regexp t))
> > tags-list))
> >(and
> > (member "With" tags-list
> >
> > There're checks for "Denny" (as a regexp) and "With" (as a string) --- this
> > is
> > supposed to be the property name, not a search term. They are both checked
> > for
> > in `tags-list'. And, finally, "Sarah" is nowhere to be seen.
> >
> > The problem, as far as I can tell, is that splitting the input at `|' to
> > get the
> > `orterms' does not work with the regular expression the function uses to
> > find
> > the constituent parts of each term. In this example, splitting the input at
> > `|'
> > makes one side get the opening brace and the other the closing brace, while
> > the
> > regexp expects both being present. Since the regexp doesn't fully match, the
> > terms are all parsed wrong. (The function doesn't recognize "With" as
> > property
> > name, for instance.) I'm still messing with it but, for now, don't really
> > know
> > how to fix the problem. I don't 100% understand the function yet...
> >
> > Regards,
>
> Hi, the solution is that it's elisp based regex, so OR is indicated with
> \| instead of just |. It might be good idea to correct the example.
>
> Best,
>
> *Daniel Fleischer*
--
Cassio Koshikumo
[BUG] Creating sparse tree with regexp property matches
Hello all,
I think there's a bug with `org-make-tags-matcher' when creating a sparse tree
using property matching with regular expressions and "or" terms. Take the
example given in the manual:
+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
+With={Sarah|Denny}+SCHEDULED>="<2008-10-11>"
If we isolate just this part:
+With={Sarah|Denny}
The resulting sparse tree does not match the right
headings. The function generates the following `tagsmatcher':
(progn
(setq org-cached-props nil)
(or
(and
(member
#("Denny" 0 5
(regexp t))
tags-list))
(and
(member "With" tags-list
There're checks for "Denny" (as a regexp) and "With" (as a string) --- this is
supposed to be the property name, not a search term. They are both checked for
in `tags-list'. And, finally, "Sarah" is nowhere to be seen.
The problem, as far as I can tell, is that splitting the input at `|' to get the
`orterms' does not work with the regular expression the function uses to find
the constituent parts of each term. In this example, splitting the input at `|'
makes one side get the opening brace and the other the closing brace, while the
regexp expects both being present. Since the regexp doesn't fully match, the
terms are all parsed wrong. (The function doesn't recognize "With" as property
name, for instance.) I'm still messing with it but, for now, don't really know
how to fix the problem. I don't 100% understand the function yet...
Regards,
--
Cassio
Re: [O] Bug: ODT export and environments
Oh, that's great! I was out of the loop for a while and didn't even know there was a new exporter on the works. Thanks and best regards, On Wed, Jan 30, 2013 at 7:47 AM, Bastien wrote: > Hi Cassio, > > Cassio Koshikumo writes: > > > I think there's a bug when exporting files to ODT using environments > > (center, quote etc.). Sample file: > > > > * Testing > > #+BEGIN_CENTER > > First line. > > > > Second line. > > #+END_CENTER > > > > When exporting that, only "First line" will have the correct style > > OrgCenter. "Second line" (and all subsequent ones) will have the > > default Text body style. > > Yes, there is a bug here. The bug is not present in the new exporter, > which will be merged very soon now. > > Thanks for reporting this, > > -- > Bastien > -- Cássio
[O] Bug: ODT export and environments
Hello, I think there's a bug when exporting files to ODT using environments (center, quote etc.). Sample file: * Testing #+BEGIN_CENTER First line. Second line. #+END_CENTER When exporting that, only "First line" will have the correct style OrgCenter. "Second line" (and all subsequent ones) will have the default Text body style. Thanks and best regards -- Cássio
Re: [O] [PATCH]: New Add defun org-mode-or-derived-mode-p
Hi, all, On the last few days I've been working on a major mode derived from org-mode. While I was at it, I've encoutered some difficulties related to those reported by the OP (Stefan). Specifically: in a lot of places, org-mode will check if it's the current major-mode and, if it's not, will refuse to perform some important task. But this poses a problem: a derived mode will always fail the test (eq major-mode 'org-mode) So, as long as org-mode relies on this test to perform some tasks, a derived mode will have non-functional pieces and bugs. Before this patch, all the checking was centralized in the defsubst `org-mode-p'. While I was developing my mode, I just changed it to (defsubst org-mode-p () (derived-mode-p 'org-mode)) Of course, this was just a temporary workaround, but I was actually planning on submitting a patch that implemented the (already discussed) `org-mode-or-derived-mode-p' alternative, replacing all calls to `org-mode-p' with calls to it. But then comes this patch, which removes `org-mode-p' altogether. So, now, there are several instances of the always-failing test on the code. Clearly, this is a big problem for anyone writing derived modes (there doesn't seem to be a lot of people doing that, but still). So, finally, here's my question: would it be possible to change all the (eq major-mode 'org-mode) tests and replace them with (derived-mode-p 'org-mode)? Is there any reason not to do this? That's effectively what happened when I changed the defsubst and I haven't noticed any problems. After all, org-mode will continue to always pass that test -- it's just that the derived modes will start to pass it too. If no ones' against it, I think I could create the patch. I haven't signed the FSF papers, but this change falls neatly into the "repetitive" category. Cheers, -- Cássio Koshikumo At Sat, 22 Oct 2011 11:31:21 +0200, Bastien wrote: > > Hi Tassilo, > > Tassilo Horn writes: > > > Ups, I've slightly misread your suggestion. Currently, there is only > > one place in org-src.el that check for being a mode derived from > > org-mode or org-mode itself. The second is useless, because > > (derived-mode-p 'org-mode) is true for org-mode, too. > > > > But as I've said, I've misread your suggestion and made a patch that > > completely erases org-mode-p and all its calls. Feel free to apply or > > discard it. :-) > > I applied this patch -- thanks for it. > > IMHO another reason for using (eq major-mode 'org-mode) instead of > (org-mode-p) is that new contributors are likely to use this more > explicit (though longer) expression before they find out that a > defsubst is available for that. > > -- > Bastien > >
Re: [Orgmode] Synopsis view - moving trees around based on a synopsis
That's a good idea. For some reason it hadn't occurred to me. I'll try to improve the code for moving the trees around when in synopsis view before posting it there. The current implementation works, but duplicates code and is a little ugly. Maybe using an advice, which is something I'm just starting to dabble with. But yeah, I'll definitely write an article there. Best, 2011/1/2 David Maus : > At Sun, 12 Dec 2010 04:56:57 -0200, > Cassio Koshikumo wrote: >> So, after fiddling a lot, I finally came up with a nice (I think) >> solution to my synopsis-associated-with-text problem >> (http://article.gmane.org/gmane.emacs.orgmode/34279/). A little >> hackish, maybe, but it works fine. >> >> Funny thing is, this solution utilizes the first method I had >> discarded: using a drawer to keep the synopsis. >> >> Here's what I wanted to achieve: >> >> I'm writing a long text. I'd like to divide it into more manageable >> chunks (using subtrees), and associate a small synopsis with each of >> them. Then, I'd like to have a view of the synopsis only, and be able >> to move the chunks based on those synopsis -- without the main text >> getting on the way. >> >> Here's the solution: >> ... > > Nice. If the hack works out fine, maybe you could write up a short > explanation for Org mode's hacks section at Worg?[1] > > Best, > -- David > > [1] http://orgmode.org/worg/org-hacks.html > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber dmj...@jabber.org > Email. dm...@ictsoc.de > -- 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
Re: [Orgmode] Synopsis view - moving trees around based on a synopsis
Oh, I definitely think you should keep the ellipsis if you like them;
that was only a suggestion. I'm working without them for a while and
it's really not that bad, at least for me. But the idea of using
unicode glyphs is nice. Gonna try it.
Now, an update: after playing with the function a little more, I came
to a new version. Its behavior is a bit different: it'll only show the
synopsis of VISIBLE subtrees. That's useful because now you can use
the synopsis view on a sparse tree; before, it would go to Contents
view automatically. (So, to replicate the old behavior, you just need
to go to Contents view with S-TAB before entering synopsis view).
Again, if anyone knows how to improve it, please leave a note.
(defun k-synopsis-view ()
(interactive)
(save-excursion
(goto-char (point-min))
(while (outline-next-heading)
(when (not (org-invisible-p))
(hide-entry)
(let ((end (save-excursion (outline-next-heading) (point
(when (re-search-forward "\\(^[ \t]*:SYNOPSIS:[. \t]*$\\)" end t)
(org-flag-drawer nil)
(re-search-forward "^[ \t]*:END:[ \t]*" nil t)
(outline-flag-region (match-beginning 0) (match-end 0) t)
))))
))
2010/12/12 Eric S Fraga :
> Cassio Koshikumo writes:
>
>
> [...]
>
>> 3. For even better results, I recommend setting org-ellipsis to " ":
>>
>> (setq org-ellipsis " ")
>
> You may wish to set this to something still conveys the hiding of text
> but which may look a little less "dirty", as you say. Maybe something
> like " ▷" (space followed by unicode character #x25b7, also known as a
> white right-pointing triangle)? This works quite nicely for me. I
> would find having a blank alone scary or, at best, confusing?
>
> --
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1
> : using Org-mode version 7.4 (release_7.4.10.g93135f)
>
--
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
[Orgmode] Synopsis view - moving trees around based on a synopsis
Hi there, So, after fiddling a lot, I finally came up with a nice (I think) solution to my synopsis-associated-with-text problem (http://article.gmane.org/gmane.emacs.orgmode/34279/). A little hackish, maybe, but it works fine. Funny thing is, this solution utilizes the first method I had discarded: using a drawer to keep the synopsis. Here's what I wanted to achieve: I'm writing a long text. I'd like to divide it into more manageable chunks (using subtrees), and associate a small synopsis with each of them. Then, I'd like to have a view of the synopsis only, and be able to move the chunks based on those synopsis -- without the main text getting on the way. Here's the solution: 1. Create a new drawer and name it SYNOPSIS. (Of course, you can choose whatever name you like.) Put the synopsis text inside this drawer. * Heading :SYNOPSIS: The synopsis goes here. :END: And the real text goes where it normally goes: on the entry body. 2. On your .emacs, paste the following function: (defun k-synopsis-view () "Show all headings (contents view) and, if any, their synopsis." (interactive) (save-excursion (goto-char (point-min)) (hide-sublevels 1) (while (re-search-forward "\\(^[ \t]*:SYNOPSIS:[. \t]*$\\)" nil t) (org-flag-drawer nil) (re-search-forward "^[ \t]*:END:[ \t]*" nil t) (outline-flag-region (match-beginning 0) (match-end 0) t)) (org-content) )) Notice that the name of the drawer is hard-coded into the function. So, if you chose another name, change it accordingly. (I /think/ this function is not too stupid, but, if anyone knows how to improve it, please do. Calling "hide-sublevels" and then "org-content" was the only way I found to show all the headings and still keep the text entry invisible when moving trees around.) Now you can M-x k-synopsis-view and see only the synopsis, without the real text. 3. For even better results, I recommend setting org-ellipsis to " ": (setq org-ellipsis " ") The "..." makes the view a little dirty. Of course, only do this if you don't mind losing the indicator that there's something hidden (I don't). 4. Now, if you're in the synopsis view and try to move trees around -- which is a primary objective of this setup -- things will not work as expected; the synopsis of the subtree you moved and a few others around it will collapse, leaving you with only the headings. (Promoting and demoting is no problem.) To solve this, I changed the functions "org-move-subtree-up" and "org-move-subtree-down" just a tad: (defun k-move-synopsis-subtree-up (&optional arg) "Move the current subtree up past ARG headlines of the same level, and keep (or enter) synopsis view." (interactive "p") (k-move-synopsis-subtree-down (- (prefix-numeric-value arg (defun k-move-synopsis-subtree-down (&optional arg) "Move the current subtree down past ARG headlines of the same level, and keep (or enter) synopsis view." (interactive "p") (setq arg (prefix-numeric-value arg)) (let ((movfunc (if (> arg 0) 'org-get-next-sibling 'org-get-last-sibling)) (ins-point (make-marker)) (cnt (abs arg)) beg beg0 end txt folded ne-beg ne-end ne-ins ins-end) ;; Select the tree (org-back-to-heading) (setq beg0 (point)) (save-excursion (setq ne-beg (org-back-over-empty-lines)) (setq beg (point))) (save-match-data (save-excursion (outline-end-of-heading) (setq folded (org-invisible-p))) (outline-end-of-subtree)) (outline-next-heading) (setq ne-end (org-back-over-empty-lines)) (setq end (point)) (goto-char beg0) (when (and (> arg 0) (org-first-sibling-p) (< ne-end ne-beg)) ;; include less whitespace (save-excursion (goto-char beg) (forward-line (- ne-beg ne-end)) (setq beg (point ;; Find insertion point, with error handling (while (> cnt 0) (or (and (funcall movfunc) (looking-at outline-regexp)) (progn (goto-char beg0) (error "Cannot move past superior level or buffer limit"))) (setq cnt (1- cnt))) (if (> arg 0) ;; Moving forward - still need to move over subtree (progn (org-end-of-subtree t t) (save-excursion (org-back-over-empty-lines) (or (bolp) (newline) (setq ne-ins (org-back-over-empty-lines)) (move-marker ins-point (point)) (setq txt (buffer-substring beg end)) (org-save-markers-in-region beg end) (delete-region beg end) (org-remove-empty-overlays-at beg) (or (= beg (point-min)) (outline-flag-region (1- beg) beg nil)) (or (bobp) (outline-flag-region (1- (point)) (point) nil)) (and (not (bolp)) (looking-at "\n") (forward-char 1)) (let ((bbb (point))) (insert-before-markers txt) (org-reinstall-markers-in-region bbb) (move-marker ins-point bbb)) (or (bolp) (insert "\n")) (setq ins-
Re: [Orgmode] Re: Two issues with :VISIBILITY: property
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 : > 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 ___ 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
[Orgmode] Re: Two issues with :VISIBILITY: property
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
[Orgmode] Two issues with :VISIBILITY: property
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 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 , 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
___
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
