From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: TODO type problem on speedbar and imenu. Date: Wed, 17 Aug 2011 18:07:01 +0200 Message-ID: <87liusnhsq.fsf@gnu.org> References: <8762mwsdhv.fsf@gmail.com> <87vcursd79.fsf@altern.org> <871uwp8vlp.fsf@gmail.com> <75CC3431-63F3-4EDA-B65C-C2BEA296FFB7@gmail.com> <87y5yt58wd.fsf@gmail.com> <82A68A74-84F0-4C21-B34E-CDEA4205F3E5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtidM-0002Gs-SS for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 12:06:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtidL-0007NJ-S0 for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 12:06:24 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:52463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtidL-0007N6-N8 for emacs-orgmode@gnu.org; Wed, 17 Aug 2011 12:06:23 -0400 Received: by fxg9 with SMTP id 9so924381fxg.0 for ; Wed, 17 Aug 2011 09:06:22 -0700 (PDT) In-Reply-To: <82A68A74-84F0-4C21-B34E-CDEA4205F3E5@gmail.com> (Carsten Dominik's message of "Wed, 17 Aug 2011 09:30:28 +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: Carsten Dominik Cc: emacs-orgmode@gnu.org, Nicolas Goaziou , Osamu OKANO Hi Carsten and Nicolas, Carsten Dominik writes: >> Notwithstanding the fontification problem, isn't "* TODO" considered as >> a valid task, whose text is "TODO" and without a keyword? > > Well, the behavior is really undefined on these border cases. There are side-effects to the current behavior. Basically, in headlines like "* TODO", the TODO keyword will not be matched correctly. So in column view, "TODO" will be displayed as the ITEM instead of the TODO keyword, which will certainly be confusing for users (see my other email). I suggest enforcing [ \t\n] instead of [ \t] to make sure those headlines are handled correctly. > My worries also stem from the possibility that the match > of these regexps now extends an additional character, and > there may be places in the code which rely on (match-end 0) > being right after (e.g.) the TODO keyword. > I do not know if this is the case, but it > is a definite possibility. Whether this is the case or not, I think the correct fix is to enforce [ \t\n] _outside_ the TODO keyword submatch. Nicolas, can you make the two suggested changes, i.e. using [ \t\n] and make sure this string is required outside the TODO keyword submatch? If you don't have time just let me know and I'll do it. Thanks! -- Bastien