From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McLean Subject: Re: org-map-entries broken? Date: Mon, 19 Mar 2012 15:49:11 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04083a9d3356c204bb9dda99 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9iaT-0007kz-Lj for emacs-orgmode@gnu.org; Mon, 19 Mar 2012 15:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9iaR-0006h4-3C for emacs-orgmode@gnu.org; Mon, 19 Mar 2012 15:49:49 -0400 Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:41599 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9iaQ-0006bm-Q5 for emacs-orgmode@gnu.org; Mon, 19 Mar 2012 15:49:47 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C967B9F6E for ; Mon, 19 Mar 2012 15:49:13 -0400 (EDT) Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BEE509F6D for ; Mon, 19 Mar 2012 15:49:13 -0400 (EDT) Received: from mail-lpp01m010-f41.google.com (unknown [209.85.215.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0C6679F69 for ; Mon, 19 Mar 2012 15:49:12 -0400 (EDT) Received: by lagz14 with SMTP id z14so6300027lag.0 for ; Mon, 19 Mar 2012 12:49:11 -0700 (PDT) In-Reply-To: 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: Charles Sebold Cc: emacs-orgmode --f46d04083a9d3356c204bb9dda99 Content-Type: text/plain; charset=ISO-8859-1 I can confirm this and add that it additionally breaks tag inheritance. I first noticed that a org-collector code block that I've been using forever was generating table that were way too long. My collector block includes =:conds ( not (string-match-p "noexport" ALLTAGS)= and the extra results I was getting all were from long trees tagged at the parent :no export: I also have some Agenda custom views that use tag inheritance that broke at the same time. I reverted =e0072f79137bbfabdf848da6865d8e4de776a549= and both behaviors corrected themselves. Mike On Monday, March 19, 2012, Charles Sebold wrote: > I think this patch may have broken org-map-entries for me: > > e0072f79137bbfabdf848da6865d8e4de776a549 is the first bad commit > commit e0072f79137bbfabdf848da6865d8e4de776a549 > Author: David Maus > Date: Sun Mar 18 18:38:50 2012 +0100 > > Require one or more spaces (+) between keyword and headline > > * org.el (org-scan-tags): Require one or more spaces (+) between > keyword and headline. > > Otherwise the re will match a line like: > > * TODO@ Foobar > > And assumes the @ to be part of the headline. > > This fixes a glitch reported by Simon Thum in > <4F53DEF7.8080604@gmx.de>. > > > Hi all, > > > > I have found some irritating behaviour, potentially a bug. I have a > > block agenda which goes like: > > > > tags-todo "@home&TODO=\"TODO\" > > > > and it displays a certain org line that reads > > > > **** TODO_ state triggers > > > > Which is just a heading for dealing with TODO state triggers, and I > > appended the _ as I don't want it to be a TODO. > > > > For example, the global TODO list and syntax highlighting does not > > consider it a todo, but C-c a m TODO="TODO" does. TODO="T" does not, > > so it's not very grave. > > > > Most likely, it's simply an inconsistency arising from not having a > > real parser. I just wanted to report it here so it may get fixed. > > :040000 040000 8f5974f2dd7cf5f0ad10db56d223ba09a6dbca80 > 624cee5569de7ef8f240ad75943be215bb823ccc M lisp > > --------------------------------------------------------------------------------- > > Try the following before and after this patch was applied, for a test result: > > --------------------------------------------------------------------------------- > * test one > * test two > * test three > > #+BEGIN_SRC emacs-lisp :results both > (org-map-entries 'org-get-heading nil nil) > #+END_SRC > --------------------------------------------------------------------------------- > > The results ought to be the three test headings in a table output. > After the patch it's blank. > -- > Charles Sebold > Ego delendus sum > > --f46d04083a9d3356c204bb9dda99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can confirm this and add that it additionally breaks tag inheritance. I f= irst noticed that a org-collector code block that I've been using forev= er was generating table that were way too long. My collector block includes= =3D:conds ( not (string-match-p "noexport" ALLTAGS)=3D and the e= xtra results I was getting all were from long trees tagged at the parent :n= o export:

I also have some Agenda custom views that use tag inheritance that brok= e at the same time.

I reverted =3De0072f79137bbfabdf848da6865d8e4de7= 76a549=3D and both behaviors corrected themselves.

Mike

On Mo= nday, March 19, 2012, Charles Sebold <csebold@gmail.com> wrote:
> I think this patch may have broken org-map-entries for me:
>
= > e0072f79137bbfabdf848da6865d8e4de776a549 is the first bad commit
&g= t; commit e0072f79137bbfabdf848da6865d8e4de776a549
> Author: David Ma= us <dmaus@ictsoc.de>
> Date: =A0 Sun Mar 18 18:38:50 2012 +0100
>
> =A0 =A0 Requi= re one or more spaces (+) between keyword and headline
>
> =A0 = =A0 * org.el (org-scan-tags): Require one or more spaces (+) between
>= ; =A0 =A0 keyword and headline.
>
> =A0 =A0 Otherwise the re will match a line like:
>
&g= t; =A0 =A0 * TODO@ Foobar
>
> =A0 =A0 And assumes the @ to be p= art of the headline.
>
> =A0 =A0 This fixes a glitch reported b= y Simon Thum in
> =A0 =A0 <4F53DEF7.808060= 4@gmx.de>.
>
> =A0 =A0 > Hi all,
> =A0 =A0 >=
> =A0 =A0 > I have found some irritating behaviour, potentially a= bug. I have a
> =A0 =A0 > block agenda which goes like:
> =A0 =A0 >
>= ; =A0 =A0 > tags-todo "@home&TODO=3D\"TODO\"
> = =A0 =A0 >
> =A0 =A0 > and it displays a certain org line that r= eads
> =A0 =A0 >
> =A0 =A0 > **** TODO_ state triggers
> =A0 =A0 >
> = =A0 =A0 > Which is just a heading for dealing with TODO state triggers, = and I
> =A0 =A0 > appended the _ as I don't want it to be a TO= DO.
> =A0 =A0 >
> =A0 =A0 > For example, the global TODO list and syntax highlighting= does not
> =A0 =A0 > consider it a todo, but C-c a m TODO=3D"= ;TODO" does. TODO=3D"T" does not,
> =A0 =A0 > so it= 's not very grave.
> =A0 =A0 >
> =A0 =A0 > Most likely, it's simply an inco= nsistency arising from not having a
> =A0 =A0 > real parser. I jus= t wanted to report it here so it may get fixed.
>
> :040000 040= 000 8f5974f2dd7cf5f0ad10db56d223ba09a6dbca80
> 624cee5569de7ef8f240ad75943be215bb823ccc M =A0 =A0 =A0lisp
>
= > ----------------------------------------------------------------------= -----------
>
> Try the following before and after this patch w= as applied, for a test result:
>
> --------------------------------------------------------------= -------------------
> * test one
> * test two
> * test th= ree
>
> =A0#+BEGIN_SRC emacs-lisp :results both
> =A0 =A0= (org-map-entries 'org-get-heading nil nil)
> =A0#+END_SRC
> -------------------------------------------------= --------------------------------
>
> The results ought to be th= e three test headings in a table output.
> After the patch it's b= lank.
> --
> Charles Sebold
> Ego delendus sum
>
> --f46d04083a9d3356c204bb9dda99--