From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [BUG] in org-property-drawer-re? Date: Tue, 01 Oct 2013 20:36:23 +0200 Message-ID: <87mwms4z4o.fsf@gmail.com> References: <87r4c4519w.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR4oP-0006sJ-Ej for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:36:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VR4oI-0001ha-3s for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:36:45 -0400 Received: from plane.gmane.org ([80.91.229.3]:58360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR4oH-0001hO-TC for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:36:38 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VR4oF-0002Af-U2 for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 20:36:35 +0200 Received: from e178190201.adsl.alicedsl.de ([85.178.190.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Oct 2013 20:36:35 +0200 Received: from tjolitz by e178190201.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Oct 2013 20:36:35 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Carsten Dominik writes: > On 1.10.2013, at 19:50, Thorsten Jolitz 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