Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ihor Radchenko <yantar92@gmail.com>]

Ignacio Casso <ignaciocasso@hotmail.com> writes:

>> Note that org-complex-heading-regexp-format does consider statistics
>> cookies, but only at the beginning/end of the headline title.
>> Unfortunately, it is impossible to provide generic printf format to
>> match a headline title with arbitrary statistics cookies inserted in the
>> middle of it.
>
> Could not something equivalent be done for COMMENT keywords and
> optionally match them at the beginning of the headline in
> `org-complex-heading-regexp-format'? Something like this:
>
>   (setq org-complex-heading-regexp-format
>         (concat "^\\(\\*+\\)"
>   	      "\\(?: +" org-todo-regexp "\\)?"
>   	      "\\(?: +\\(\\[#.\\]\\)\\)?"
>   	      "\\(?: +"
> +             ;; Headline might be commented
> +             "\\(COMMENT \\)?
>   	      ;; Stats cookies can be stuck to body.
>   	      "\\(?:\\[[0-9%%/]+\\] *\\)*"
>   	      "\\(%s\\)"
>   	      "\\(?: *\\[[0-9%%/]+\\]\\)*"
>   	      "\\)"
>   	      "\\(?:[ \t]+\\(:[[:alnum:]_@#%%:]+:\\)\\)?"
>   	      "[ \t]*$"))
>
> This would fix the problem I really cared about: being able to use a
> headline as capture target regardless of whether it is commented or
> not. Getting the headline text was never important to me, so I don't
> really care that much about `org-complex-heading-regexp'.

Sounds reasonable. Could you prepare a patch?
COMMENT should be inside a shy group and note that there might be an
arbitrary number of space after COMMENT string.

>> I generally dislike the idea of the available plethora of analytic
>> regexps with numbered match groups.
>
> Do you mean that there is no way to specify an optional string in a
> regular expression without wrapping it in a parenthesized group, which
> would break the match group numbering backwards compatibility? I'm not
> that familiar with regular expressions, but if that's the case I
> completely agree with your last statement.

Not exactly. We could use shy (unnumbered) match group and not break the
group numbers. However, adding an extra optional match means that we can
break an old code that could be relying on the next group to contain
this optional match:

Old code:
(when (string-match-p "COMMENT" (match-string 1)) ...)

Before "\\(.+\\)"
After "\\(?:COMMENT\\)?\\(.+\\)"

The old code will never match COMMENT when the new regexp is used.

Best,
Ihor