This topic was brought up again in https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html, I continue the discussion here:
>> Still, I think it might be interesting to compare this topic with the >> one I linked in my reply, >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html, >> which it's basically the same bug report but about COMMENT keywords. In >> that regard, I have tested that org-capture targets do work regardless >> of statistcs cookies. Could not something equivalent be done so that >> they also work regardless of COMMENT keywords? Feel free to reply in >> that other thread if you feel this is off-topic here. > >> This bug is related with the issue I reported in >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The >> problem is that `org-heading-components' uses >> `org-complex-heading-regexp', which does not consider statistics >> cookies, and neither COMMENT keywords as I reported. I think it should be >> updated to consider both. > > 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'. > As for your other report, it is a hard one - org-complex-heading-regexp > is hard to modify because we guarantee certain match groups and its hard > to fit COMMENT in there without breaking backward-compatibility. > > 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. --Ignacio
