From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [BUG] in org-property-drawer-re? Date: Tue, 1 Oct 2013 20:44:10 +0200 Message-ID: <08DC8B04-182A-4B69-A5A7-F4F7A98F621C@gmail.com> References: <87r4c4519w.fsf@gmail.com> <87mwms4z4o.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C4CBEC13-47B9-47C6-81A4-80C238766C5E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR4vn-0000P3-8C for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:44:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VR4ve-0003ns-Pk for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:44:23 -0400 Received: from mail-ee0-x230.google.com ([2a00:1450:4013:c00::230]:36529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR4ve-0003ni-CD for emacs-orgmode@gnu.org; Tue, 01 Oct 2013 14:44:14 -0400 Received: by mail-ee0-f48.google.com with SMTP id l10so3570794eei.7 for ; Tue, 01 Oct 2013 11:44:13 -0700 (PDT) In-Reply-To: <87mwms4z4o.fsf@gmail.com> 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: Thorsten Jolitz Cc: emacs-orgmode@gnu.org --Apple-Mail=_C4CBEC13-47B9-47C6-81A4-80C238766C5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1.10.2013, at 20:36, Thorsten Jolitz wrote: > Carsten Dominik writes: >=20 >> On 1.10.2013, at 19:50, Thorsten Jolitz wrote: >>=20 >>>=20 >>> Hi List, >>>=20 >>> for the navi-mode keyword-search for complete property drawers I = copied >>>=20 >>> ,----------------------- >>> | org-property-drawer-re >>> `----------------------- >>>=20 >>> from org.el: >>>=20 >>> #+begin_src emacs-lisp >>> (concat "\\(" org-property-start-re "\\)[^\000]*\\(" >>> org-property-end-re "\\)\n?") >>> #+end_src >>>=20 >>> #+results: >>> : \(^[ ]*:PROPERTIES:[ ]*$\)[^\\000]*\(^[ ]*:END:[ = ]*$\) >>> : ? >>>=20 >>> A bit unreadable, but you get the message ... here is my hopefully = equivalent >>> version: >>>=20 >>> ,-------------------------------------------------------------- >>> | (:propertydrawer >>> | . (concat "\\(^[\\s\\t]*:PROPERTIES:[\\s\\t]*$\\)[^\\000]*" >>> | "\\(^[\\s\\t]*:END:[\\s\\t]*$\\)\\n?")) >>> `-------------------------------------------------------------- >>>=20 >>> But this did not match correctly in Bernt Hansens tutorial: >>=20 >> 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.... >=20 >=20 > But, if this is equivalent to the #+results: block above, it is = defined > in org.el without that one ? indicated that makes the difference: >=20 > ,----------------------------------------------------------- > | (:propertydrawer > | . (concat "\\(^[ \\t]*:PROPERTIES:[ \\t]*$\\)[^\\000]*?" <=3D > | "\\(^[ \\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 >=20 >> Yes, you need the star to make it non-greedy. >=20 > the '?' I guess ... >=20 >> 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. >=20 > ok, I see >=20 >> 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. >=20 > thanks god for M-x regexp-builder ;) >=20 >>> PS >>> Can anybody explain this marvelous construct in the regexp: >>>=20 >>> ,--------- >>> | [^\\000] >>> `--------- >>=20 >> 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. >=20 > This is a very nice trick, and the alternative looks easy too - I have > to remember this. >=20 >>> I often pondered about how to achieve its effect with other means, = since >>> I did not find it in the Emacs Lisp manual. >>=20 >> There you go - sometimes a brain is better than the Emacs manual :) >=20 > Thanks a lot >=20 > -- > cheers, > Thorsten >=20 >=20 --Apple-Mail=_C4CBEC13-47B9-47C6-81A4-80C238766C5E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJSSxf6AAoJEO+gg/nAZuwM2DcIALWH9EYYISQia7b1nmXCilLx rB78b+jRwE883shRpjX1AQTKnAQ+GjTR1zliKKQegLAF0KsvGqQOvOf51ONBEm6n R6iV6D+SO92n9SBLWawxnCa1RfJXRyETI6M+CL+fnMxcWb7z8waBXViOkwmP6cS9 LvvanzcV1ygxBnp+LIe1FdQ/viL5geJuR0wlf/gIsxLJgN0wB3yPkRzqlHiKgrOi 1vY+oNxHN/+Y1zkdaTS91ANsz63pu+2HhWYm2vEwqErss0Fhzg/j0KgbDNdRWacQ PJBBSCuApKJRQ0QY6f7tBsPe9LEs7qFuhQIBj8DANEl9Aqsa+em9nJo6HpUd9MI= =4UN0 -----END PGP SIGNATURE----- --Apple-Mail=_C4CBEC13-47B9-47C6-81A4-80C238766C5E--