* [BUG] in org-property-drawer-re?
@ 2013-10-01 17:50 Thorsten Jolitz
2013-10-01 18:17 ` Carsten Dominik
0 siblings, 1 reply; 9+ messages in thread
From: Thorsten Jolitz @ 2013-10-01 17:50 UTC (permalink / raw)
To: emacs-orgmode
Hi List,
for the navi-mode keyword-search for complete property drawers I copied
,-----------------------
| org-property-drawer-re
`-----------------------
from org.el:
#+begin_src emacs-lisp
(concat "\\(" org-property-start-re "\\)[^\000]*\\("
org-property-end-re "\\)\n?")
#+end_src
#+results:
: \(^[ ]*:PROPERTIES:[ ]*$\)[^\\000]*\(^[ ]*:END:[ ]*$\)
: ?
A bit unreadable, but you get the message ... here is my hopefully equivalent
version:
,--------------------------------------------------------------
| (:propertydrawer
| . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*"
| "\\(^[\\s\\t]*:END:[\\s\\t]*$\\)\\n?"))
`--------------------------------------------------------------
But this did not match correctly in Bernt Hansens tutorial:
,--------------------------------------------------------------------------
| 43::PROPERTIES:
| ::CUSTOM_ID: Setup
| ::END:
| 131::PROPERTIES:
| ::CUSTOM_ID: OrgFiles
| ::END:
| 185::PROPERTIES:
| ::CUSTOM_ID: AgendaSetup
| ::END:
| :
| :Here is my current =org-agenda-files= setup.
| :#+begin_src emacs-lisp :tangle no
| : (setq org-agenda-files (quote ("~/git/org"
| : "~/git/org/client1"
| : "~/git/org/bzflag"
| : "~/git/client2")))
| :#+end_src
| :
| :#+begin_src emacs-lisp :tangle yes :exports none
| : ;; The following setting is different from the document so that you
| : ;; can override the document org-agenda-files by setting your
| : ;; org-agenda-files in the variable org-user-agenda-files
| : ;;
| : (if (boundp 'org-user-agenda-files)
| : (setq org-agenda-files org-user-agenda-files)
| : (setq org-agenda-files (quote ("~/git/org"
| : "~/git/org/client1"
| : "~/git/org/bzflag"
| : "~/git/client2"))))
| :
| :#+end_src
`--------------------------------------------------------------------------
I had to add two ? after the * and delete the final \n
,-------------------------------------------------------------
| (:propertydrawer
| . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*?"
| "\\(^[\\s\\t]*:END:[\\s\\t]*?$\\)"))
`-------------------------------------------------------------
to get the desired results:
,---------------------------------
| 43::PROPERTIES:
| ::CUSTOM_ID: Setup
| ::END:
| 131::PROPERTIES:
| ::CUSTOM_ID: OrgFiles
| ::END:
| 185::PROPERTIES:
| ::CUSTOM_ID: AgendaSetup
| ::END:
| 234::PROPERTIES:
| ::CUSTOM_ID: OrgFileStructure
| ::END:
`---------------------------------
A bug in the regexp?
PS
Can anybody explain this marvelous construct in the regexp:
,---------
| [^\\000]
`---------
I often pondered about how to achieve its effect with other means, since
I did not find it in the Emacs Lisp manual.
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [BUG] in org-property-drawer-re? 2013-10-01 17:50 [BUG] in org-property-drawer-re? Thorsten Jolitz @ 2013-10-01 18:17 ` Carsten Dominik 2013-10-01 18:36 ` Thorsten Jolitz 2013-10-02 9:55 ` Nicolas Goaziou 0 siblings, 2 replies; 9+ messages in thread From: Carsten Dominik @ 2013-10-01 18:17 UTC (permalink / raw) To: Thorsten Jolitz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 4908 bytes --] On 1.10.2013, at 19:50, Thorsten Jolitz <tjolitz@gmail.com> wrote: > > Hi List, > > for the navi-mode keyword-search for complete property drawers I copied > > ,----------------------- > | org-property-drawer-re > `----------------------- > > from org.el: > > #+begin_src emacs-lisp > (concat "\\(" org-property-start-re "\\)[^\000]*\\(" > org-property-end-re "\\)\n?") > #+end_src > > #+results: > : \(^[ ]*:PROPERTIES:[ ]*$\)[^\\000]*\(^[ ]*:END:[ ]*$\) > : ? > > A bit unreadable, but you get the message ... here is my hopefully equivalent > version: > > ,-------------------------------------------------------------- > | (:propertydrawer > | . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*" > | "\\(^[\\s\\t]*:END:[\\s\\t]*$\\)\\n?")) > `-------------------------------------------------------------- > > But this did not match correctly in Bernt Hansens tutorial: Indeed, this is a bad regular expression, it is too greedy and will match all the way to the last :END: line it can find. also, \\s is wrong, it should be just a space, so "[ \t]". Luckily this regular expression does not seem to be used in Org as far as I can see.... > > ,-------------------------------------------------------------------------- > | 43::PROPERTIES: > | ::CUSTOM_ID: Setup > | ::END: > | 131::PROPERTIES: > | ::CUSTOM_ID: OrgFiles > | ::END: > | 185::PROPERTIES: > | ::CUSTOM_ID: AgendaSetup > | ::END: > | : > | :Here is my current =org-agenda-files= setup. > | :#+begin_src emacs-lisp :tangle no > | : (setq org-agenda-files (quote ("~/git/org" > | : "~/git/org/client1" > | : "~/git/org/bzflag" > | : "~/git/client2"))) > | :#+end_src > | : > | :#+begin_src emacs-lisp :tangle yes :exports none > | : ;; The following setting is different from the document so that you > | : ;; can override the document org-agenda-files by setting your > | : ;; org-agenda-files in the variable org-user-agenda-files > | : ;; > | : (if (boundp 'org-user-agenda-files) > | : (setq org-agenda-files org-user-agenda-files) > | : (setq org-agenda-files (quote ("~/git/org" > | : "~/git/org/client1" > | : "~/git/org/bzflag" > | : "~/git/client2")))) > | : > | :#+end_src > `-------------------------------------------------------------------------- > > I had to add two ? You only need the first - the second is OK. > after the * and delete the final \n > > ,------------------------------------------------------------- > | (:propertydrawer > | . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*?" > | "\\(^[\\s\\t]*:END:[\\s\\t]*?$\\)")) > `------------------------------------------------------------- Yes, you need the star to make it non-greedy. However, you can leave the \n after you have corrected the character class to "[ \t]" - it just means that the \n will be part of the match, but still allow for the possibility that the last line hits the end of the buffer. Ahhhh, regular expressions. I think in my entire history as a programmer, learning about regular expressions was the biggest braintrip I ever had - still love them. > > to get the desired results: > > ,--------------------------------- > | 43::PROPERTIES: > | ::CUSTOM_ID: Setup > | ::END: > | 131::PROPERTIES: > | ::CUSTOM_ID: OrgFiles > | ::END: > | 185::PROPERTIES: > | ::CUSTOM_ID: AgendaSetup > | ::END: > | 234::PROPERTIES: > | ::CUSTOM_ID: OrgFileStructure > | ::END: > `--------------------------------- > > A bug in the regexp? > > PS > Can anybody explain this marvelous construct in the regexp: > > ,--------- > | [^\\000] > `--------- This is just a cheep way to match any character at all, because \000 should not be part of any string (in C it indicates the end of a string). In principle you could put any character you are sure will not turn up, but \000 seems to be the safest choice. It is faster (I think) than "\\(.\\|\n\\)*" because the first will just run fast and streight with a table lookup while the latter need to always alternate between two alternatives. I have not timed it, though. > > I often pondered about how to achieve its effect with other means, since > I did not find it in the Emacs Lisp manual. There you go - sometimes a brain is better than the Emacs manual :) Regards - Carsten > > -- > cheers, > Thorsten > > [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-01 18:17 ` Carsten Dominik @ 2013-10-01 18:36 ` Thorsten Jolitz 2013-10-01 18:44 ` Carsten Dominik 2013-10-02 9:55 ` Nicolas Goaziou 1 sibling, 1 reply; 9+ messages in thread From: Thorsten Jolitz @ 2013-10-01 18:36 UTC (permalink / raw) To: emacs-orgmode Carsten Dominik <carsten.dominik@gmail.com> writes: > On 1.10.2013, at 19:50, Thorsten Jolitz <tjolitz@gmail.com> wrote: > >> >> Hi List, >> >> for the navi-mode keyword-search for complete property drawers I copied >> >> ,----------------------- >> | org-property-drawer-re >> `----------------------- >> >> from org.el: >> >> #+begin_src emacs-lisp >> (concat "\\(" org-property-start-re "\\)[^\000]*\\(" >> org-property-end-re "\\)\n?") >> #+end_src >> >> #+results: >> : \(^[ ]*:PROPERTIES:[ ]*$\)[^\\000]*\(^[ ]*:END:[ ]*$\) >> : ? >> >> A bit unreadable, but you get the message ... here is my hopefully equivalent >> version: >> >> ,-------------------------------------------------------------- >> | (:propertydrawer >> | . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*" >> | "\\(^[\\s\\t]*:END:[\\s\\t]*$\\)\\n?")) >> `-------------------------------------------------------------- >> >> But this did not match correctly in Bernt Hansens tutorial: > > Indeed, this is a bad regular expression, it is too greedy and will > match all the way to the last :END: line it can find. also, \\s is > wrong, it should be just a space, so "[ \t]". Luckily > this regular expression does not seem to be used in Org as far > as I can see.... But, if this is equivalent to the #+results: block above, it is defined in org.el without that one ? indicated that makes the difference: ,----------------------------------------------------------- | (:propertydrawer | . (concat "\\(^[ \\t]*:PROPERTIES:[ \\t]*$\\)[^\\000]*?" <= | "\\(^[ \\t]*:END:[ \\t]*$\\)\\n?")) `----------------------------------------------------------- > Yes, you need the star to make it non-greedy. the '?' I guess ... > However, you can leave the \n after you have corrected the > character class to "[ \t]" - it just means that > the \n will be part of the match, but still allow > for the possibility that the last line hits the end > of the buffer. ok, I see > Ahhhh, regular expressions. I think in my entire history > as a programmer, learning about regular expressions was > the biggest braintrip I ever had - still love them. thanks god for M-x regexp-builder ;) >> PS >> Can anybody explain this marvelous construct in the regexp: >> >> ,--------- >> | [^\\000] >> `--------- > > This is just a cheep way to match any character at all, because \000 should > not be part of any string (in C it indicates the end of a string). > In principle you could put any character you are sure will not turn up, > but \000 seems to be the safest choice. It is > faster (I think) than "\\(.\\|\n\\)*" because the first will > just run fast and streight with a table lookup while the > latter need to always alternate between two alternatives. > I have not timed it, though. This is a very nice trick, and the alternative looks easy too - I have to remember this. >> I often pondered about how to achieve its effect with other means, since >> I did not find it in the Emacs Lisp manual. > > There you go - sometimes a brain is better than the Emacs manual :) Thanks a lot -- cheers, Thorsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-01 18:36 ` Thorsten Jolitz @ 2013-10-01 18:44 ` Carsten Dominik 0 siblings, 0 replies; 9+ messages in thread From: Carsten Dominik @ 2013-10-01 18:44 UTC (permalink / raw) To: Thorsten Jolitz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 3605 bytes --] On 1.10.2013, at 20:36, Thorsten Jolitz <tjolitz@gmail.com> wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> On 1.10.2013, at 19:50, Thorsten Jolitz <tjolitz@gmail.com> wrote: >> >>> >>> Hi List, >>> >>> for the navi-mode keyword-search for complete property drawers I copied >>> >>> ,----------------------- >>> | org-property-drawer-re >>> `----------------------- >>> >>> from org.el: >>> >>> #+begin_src emacs-lisp >>> (concat "\\(" org-property-start-re "\\)[^\000]*\\(" >>> org-property-end-re "\\)\n?") >>> #+end_src >>> >>> #+results: >>> : \(^[ ]*:PROPERTIES:[ ]*$\)[^\\000]*\(^[ ]*:END:[ ]*$\) >>> : ? >>> >>> A bit unreadable, but you get the message ... here is my hopefully equivalent >>> version: >>> >>> ,-------------------------------------------------------------- >>> | (:propertydrawer >>> | . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*" >>> | "\\(^[\\s\\t]*:END:[\\s\\t]*$\\)\\n?")) >>> `-------------------------------------------------------------- >>> >>> But this did not match correctly in Bernt Hansens tutorial: >> >> Indeed, this is a bad regular expression, it is too greedy and will >> match all the way to the last :END: line it can find. also, \\s is >> wrong, it should be just a space, so "[ \t]". Luckily >> this regular expression does not seem to be used in Org as far >> as I can see.... > > > But, if this is equivalent to the #+results: block above, it is defined > in org.el without that one ? indicated that makes the difference: > > ,----------------------------------------------------------- > | (:propertydrawer > | . (concat "\\(^[ \\t]*:PROPERTIES:[ \\t]*$\\)[^\\000]*?" <= > | "\\(^[ \\t]*:END:[ \\t]*$\\)\\n?")) > `----------------------------------------------------------- Yes. this is a bug, fortunately inconsequential since org does its property matching in a different way. Anyway, this bug is fixed in master. - Carsten > >> Yes, you need the star to make it non-greedy. > > the '?' I guess ... > >> However, you can leave the \n after you have corrected the >> character class to "[ \t]" - it just means that >> the \n will be part of the match, but still allow >> for the possibility that the last line hits the end >> of the buffer. > > ok, I see > >> Ahhhh, regular expressions. I think in my entire history >> as a programmer, learning about regular expressions was >> the biggest braintrip I ever had - still love them. > > thanks god for M-x regexp-builder ;) > >>> PS >>> Can anybody explain this marvelous construct in the regexp: >>> >>> ,--------- >>> | [^\\000] >>> `--------- >> >> This is just a cheep way to match any character at all, because \000 should >> not be part of any string (in C it indicates the end of a string). >> In principle you could put any character you are sure will not turn up, >> but \000 seems to be the safest choice. It is >> faster (I think) than "\\(.\\|\n\\)*" because the first will >> just run fast and streight with a table lookup while the >> latter need to always alternate between two alternatives. >> I have not timed it, though. > > This is a very nice trick, and the alternative looks easy too - I have > to remember this. > >>> I often pondered about how to achieve its effect with other means, since >>> I did not find it in the Emacs Lisp manual. >> >> There you go - sometimes a brain is better than the Emacs manual :) > > Thanks a lot > > -- > cheers, > Thorsten > > [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-01 18:17 ` Carsten Dominik 2013-10-01 18:36 ` Thorsten Jolitz @ 2013-10-02 9:55 ` Nicolas Goaziou 2013-10-02 11:05 ` Carsten Dominik 2013-10-02 11:38 ` Thorsten Jolitz 1 sibling, 2 replies; 9+ messages in thread From: Nicolas Goaziou @ 2013-10-02 9:55 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode, Thorsten Jolitz Hello, Carsten Dominik <carsten.dominik@gmail.com> writes: > This is just a cheep way to match any character at all, because \000 should > not be part of any string (in C it indicates the end of a string). > In principle you could put any character you are sure will not turn up, > but \000 seems to be the safest choice. It is > faster (I think) than "\\(.\\|\n\\)*" because the first will > just run fast and streight with a table lookup while the > latter need to always alternate between two alternatives. > I have not timed it, though. On that topic, I would add that "^\000" must be used with care, as it can lead to a stack overflow in regexp matcher error quite easily. In particular, it may be safe to use it to match a property drawer, which will not be very large, but I think it's wrong to use it to match regular blocks or drawers, which can have arbitrary long size. For example a regexp like "[^\000]\\." will fail when matching around 500 lines (72 characters long). Of course, constructs like "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting to use "^\000" even though a regexp may not be the correct answer to the problem. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-02 9:55 ` Nicolas Goaziou @ 2013-10-02 11:05 ` Carsten Dominik 2013-10-02 11:14 ` Nicolas Goaziou 2013-10-02 11:38 ` Thorsten Jolitz 1 sibling, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2013-10-02 11:05 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, Thorsten Jolitz [-- Attachment #1: Type: text/plain, Size: 1498 bytes --] On Oct 2, 2013, at 11:55 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Hello, > > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> This is just a cheep way to match any character at all, because \000 should >> not be part of any string (in C it indicates the end of a string). >> In principle you could put any character you are sure will not turn up, >> but \000 seems to be the safest choice. It is >> faster (I think) than "\\(.\\|\n\\)*" because the first will >> just run fast and streight with a table lookup while the >> latter need to always alternate between two alternatives. >> I have not timed it, though. > > On that topic, I would add that "^\000" must be used with care, as it > can lead to a stack overflow in regexp matcher error quite easily. In > particular, it may be safe to use it to match a property drawer, which > will not be very large, but I think it's wrong to use it to match > regular blocks or drawers, which can have arbitrary long size. > > For example a regexp like "[^\000]\\." will fail when matching around > 500 lines (72 characters long). Of course, constructs like > "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting > to use "^\000" even though a regexp may not be the correct answer to the > problem. Yes, I agree. This is why the real matching Org does is first looking for a begin line, and then for the END line, in two independent searches. Much better and safer. - Carsten [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-02 11:05 ` Carsten Dominik @ 2013-10-02 11:14 ` Nicolas Goaziou 2013-10-02 11:37 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Nicolas Goaziou @ 2013-10-02 11:14 UTC (permalink / raw) To: Carsten Dominik; +Cc: Thorsten Jolitz, emacs-orgmode Carsten Dominik <carsten.dominik@gmail.com> writes: > This is why the real matching Org does is first looking for a begin > line, and then for the END line, in two independent searches. Not always: see `org-block-regexp' and `org-babel-src-block-regexp', for example. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-02 11:14 ` Nicolas Goaziou @ 2013-10-02 11:37 ` Carsten Dominik 0 siblings, 0 replies; 9+ messages in thread From: Carsten Dominik @ 2013-10-02 11:37 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Thorsten Jolitz, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 542 bytes --] On Oct 2, 2013, at 1:14 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> This is why the real matching Org does is first looking for a begin >> line, and then for the END line, in two independent searches. > > Not always: see `org-block-regexp' and `org-babel-src-block-regexp', for > example. I see. Well, I guess so far we have not run into trouble, so we can save changing this of another time. - Carsten > > > Regards, > > -- > Nicolas Goaziou [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [BUG] in org-property-drawer-re? 2013-10-02 9:55 ` Nicolas Goaziou 2013-10-02 11:05 ` Carsten Dominik @ 2013-10-02 11:38 ` Thorsten Jolitz 1 sibling, 0 replies; 9+ messages in thread From: Thorsten Jolitz @ 2013-10-02 11:38 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <n.goaziou@gmail.com> writes: Hello, > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> This is just a cheep way to match any character at all, because \000 should >> not be part of any string (in C it indicates the end of a string). >> In principle you could put any character you are sure will not turn up, >> but \000 seems to be the safest choice. It is >> faster (I think) than "\\(.\\|\n\\)*" because the first will >> just run fast and streight with a table lookup while the >> latter need to always alternate between two alternatives. >> I have not timed it, though. > > On that topic, I would add that "^\000" must be used with care, as it > can lead to a stack overflow in regexp matcher error quite easily. In > particular, it may be safe to use it to match a property drawer, which > will not be very large, but I think it's wrong to use it to match > regular blocks or drawers, which can have arbitrary long size. > > For example a regexp like "[^\000]\\." will fail when matching around > 500 lines (72 characters long). Of course, constructs like > "\\(.\\|\n\\)*\\." will also fail, but my point is that it is tempting > to use "^\000" even though a regexp may not be the correct answer to the > problem. Conceptually it looks perfect(ly simple) to me, and I'm happy that I discovered the pattern now by accident (better late than never), but stack overflow is of course an important point. Reminds me of my little [[https://github.com/tj64/org-hlc][org-hlc.el]] library (hidden lines cookies) ,------------------------------------------------------------------------------- | org-hlc.el implements hidden-lines-cookies for Org-mode | | hidden-lines-cookies (hlc) are small cookies at the end of each folded (and | visible) headline in an Org-mode buffer that show the number of hidden lines | before the next visible headline. | | hidden-lines-cookies can be handled with three user commands: | org-hlc-show-hidden-lines-cookies, org-hlc-hide-hidden-lines-cookies, and the | convenience command org-hlc-toggle-hidden-lines-cookies that toggles between | the two other commands conditional on the last one executed. | | The appearance of the cookies can be customized by changing the values of four | customizable variables: org-hlc-hidden-lines-cookie-left-delimiter (with | default value "["), org-hlc-hidden-lines-cookie-right-delimiter (with default | value "]"), org-hlc-hidden-lines-cookie-left-signal-char (with default value | "#") and org-hlc-hidden-lines-cookie-right-signal-char (with default value | ""). | | Thus an exemplary folded headline with 165 hidden lines before the next | visible headline might look like this when hidden-lines-cookies are shown: | | ,----------------- | *** Headline [#165] `----------------- | `------------------------------------------------------------------------------- that was conceptually all 'wrong': - the cookies are written in the original buffer (but that could easily be changed to a temporary indirect buffer) - cookies are only shown/updated with explicit user commands but it works even in 7000 lines .el or .org files. The other attempt to 'do it right' based on a library by Francois Pinard, [[https://github.com/tj64/org-weights][org-weights.el]], uses overlays and dynamic updates of the tree-weights via change hooks - much better in theory - but somehow overwhelms Emacs capacities in big files so that user experience is affected. -- cheers, Thorsten ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-10-02 11:38 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-10-01 17:50 [BUG] in org-property-drawer-re? Thorsten Jolitz 2013-10-01 18:17 ` Carsten Dominik 2013-10-01 18:36 ` Thorsten Jolitz 2013-10-01 18:44 ` Carsten Dominik 2013-10-02 9:55 ` Nicolas Goaziou 2013-10-02 11:05 ` Carsten Dominik 2013-10-02 11:14 ` Nicolas Goaziou 2013-10-02 11:37 ` Carsten Dominik 2013-10-02 11:38 ` Thorsten Jolitz
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).