Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Nicolas Goaziou writes: > Bastien writes: > >> I know, but the users should not have to guess this. >> Maybe a note about the allowed structure here in the >> manual would be useful. > > Done in e84c1d8442b857f9275e86bb34f12811f49fcdd6. Perfect, thanks, -- Bastien
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Bastien writes: > I know, but the users should not have to guess this. > Maybe a note about the allowed structure here in the > manual would be useful. Done in e84c1d8442b857f9275e86bb34f12811f49fcdd6. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Hi Nicolas, Nicolas Goaziou writes: > So the COMMENT keyword in the second headline is not valid. I know, but the users should not have to guess this. Maybe a note about the allowed structure here in the manual would be useful. -- Bastien
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Bastien writes: > Speaking of consistency, I noticed this minor glitch: > > * NEXT COMMENT A headline [0/2] > > - [ ] A > - [ ] B > > * NEXT [#A] [1/2] COMMENT Another headline > > - [X] A > - [ ] B > > See that the second COMMENT is not fontified and I think > it will not be processed correctly. > > Now that COMMENT will not be always the first word of a > headline, we should mention that TODO keywords and priority > cookies are allowed before a COMMENT keyword, while stats > cookies are not. (Or allow stats cookies for simplicity's > sake.) COMMENT has to be at the start of the headline text, which starts after any TODO keyword and priority character (see `org-heading-components'). So the COMMENT keyword in the second headline is not valid. The manual specifies: Also entire subtrees starting with the keyword ‘COMMENT’ will never be exported We could be more explicit. In any case, COMMENT cannot be put anywhere. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Hi Nicolas, Nicolas Goaziou writes: > Nicolas Goaziou writes: > >> Thus, this patch >> >> - properly fontifies headlines with both a regular keyword and >>a COMMENT keyword, >> >> - fixes `org-toggle-comment' and `org-todo' to handle both COMMENT >>keyword and another one >> >> - adds some consistency to functions implementing their own COMMENT >>matching (e.g., with or without case-sensitivity). > > Applied. Thanks -- this is a welcome improvement. Speaking of consistency, I noticed this minor glitch: * NEXT COMMENT A headline [0/2] - [ ] A - [ ] B * NEXT [#A] [1/2] COMMENT Another headline - [X] A - [ ] B See that the second COMMENT is not fontified and I think it will not be processed correctly. Now that COMMENT will not be always the first word of a headline, we should mention that TODO keywords and priority cookies are allowed before a COMMENT keyword, while stats cookies are not. (Or allow stats cookies for simplicity's sake.) What do you think? -- Bastien
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Nicolas Goaziou writes: > Thus, this patch > > - properly fontifies headlines with both a regular keyword and >a COMMENT keyword, > > - fixes `org-toggle-comment' and `org-todo' to handle both COMMENT >keyword and another one > > - adds some consistency to functions implementing their own COMMENT >matching (e.g., with or without case-sensitivity). Applied. -- Nicolas Goaziou
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
Hello, Samuel Wales writes: > does this preserve todo keyword font locking This is one goal of the patch. > and sorting? IIRC, TODO-based sorting refers to `org-todo-keywords-1', which doesn't include "COMMENT", so I don't think this changes sorting (i.e., sorting ignores COMMENT keywords). > does archive work the same way? I didn't touch to archive tag (but there's some work to do here to, as a first step, `org-in-archived-heading-p' would be nice). Note that ARCHIVE is a tag, though. > i presume it is a coincidence that this message comes after mine which > mentioned font locking and sorting No it isn't. Your message recalled me this needed to be fixed. > as the fix to that message is to not evaluate or export call lines > that are not supposed to be exported. i would not find this change to > be a suitable workaround for that. I do not want to provide a workaround for what I do not consider to be a bug. Export and Babel are two different parts of Org that happen to have a non-empty intersection. "No Export" doesn't have to mean "No Babel" (unless you use a COMMENT keyword, that is). Anyway that's another topic. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Properly handle keyword + COMMENT keyword
does this preserve todo keyword font locking and sorting? it is an interesting change if so, and i would probably find it useful. does archive work the same way? i presume it is a coincidence that this message comes after mine which mentioned font locking and sorting, as the fix to that message is to not evaluate or export call lines that are not supposed to be exported. i would not find this change to be a suitable workaround for that. however, i like the idea of commenting out a headline not changing sorting and font locking. i have always called these quasi-keywords.
[O] [RFC] Properly handle keyword + COMMENT keyword
Hello,
COMMENT keyword is not always clearly defined in Org. Some parts
consider it is a regular keyword as treat it as such (e.g. `org-todo')
whereas some others see it as an additional keyword (e.g.,
`org-priority').
I think the latter makes more sense, and, as a consequence, Org Syntax
(http://orgmode.org/worg/dev/org-syntax.html) defines it that way. Much
like :ARCHIVE:, COMMENT provides an additional property to the headline,
without limiting it whatsoever.
In other words, the following should be valid:
* TODO COMMENT Headline
and, according to Org Syntax, so should this:
* TODO [#A] COMMENT Headline
Though, COMMENT keyword must come after any other keyword and priority,
if any. So the following is /not/ valid:
* COMMENT TODO Headline
Thus, this patch
- properly fontifies headlines with both a regular keyword and
a COMMENT keyword,
- fixes `org-toggle-comment' and `org-todo' to handle both COMMENT
keyword and another one
- adds some consistency to functions implementing their own COMMENT
matching (e.g., with or without case-sensitivity).
WDYT?
--
Nicolas Goaziou
>From 0a16a1136dbda9deec40b9a72e7dd0a5d648db71 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Mon, 24 Mar 2014 21:46:00 +0100
Subject: [PATCH] Fix COMMENT keyword when stacked with a regular keyword
* lisp/org.el (org-set-font-lock-defaults): Fix headline fontification
when keywords are stacked.
(org-toggle-comment): Properly toggle COMMENT keyword when a regular
keyword is already present.
(org-todo, org-agenda-prepare-buffers): Correctly match a commented
heading.
* lisp/org-colview.el (org-columns-capture-view): Correctly match
a commented heading.
* testing/lisp/test-org.el (test-org/toggle-comment): New test.
---
lisp/org-colview.el | 8 +++
lisp/org.el | 40 +
testing/lisp/test-org.el | 58
3 files changed, 82 insertions(+), 24 deletions(-)
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 07d140f..9ebea98 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -1201,8 +1201,6 @@ containing the title row and all other rows. Each row is a list
of fields."
(save-excursion
(let* ((title (mapcar 'cadr org-columns-current-fmt-compiled))
- (re-comment (format org-heading-keyword-regexp-format
- org-comment-string))
(re-archive (concat ".*:" org-archive-tag ":"))
(n (length title)) row tbl)
(goto-char (point-min))
@@ -1214,9 +1212,9 @@ of fields."
(/ (1+ (length (match-string 1))) 2)
(length (match-string 1)
(get-char-property (match-beginning 0) 'org-columns-key))
- (when (save-excursion
- (goto-char (point-at-bol))
- (or (looking-at re-comment)
+ (when (or (org-in-commented-heading-p t)
+ (save-excursion
+ (goto-char (point-at-bol))
(looking-at re-archive)))
(org-end-of-subtree t)
(throw 'next t))
diff --git a/lisp/org.el b/lisp/org.el
index ef0bc3f..94bda2a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6343,9 +6343,11 @@ needs to be inserted at a specific position in the font-lock sequence.")
;; Code
'(org-activate-code (1 'org-code t))
;; COMMENT
- (list (format org-heading-keyword-regexp-format
- (concat "\\(" org-comment-string "\\)"))
- '(2 'org-special-keyword t))
+ (list (format
+ "^\\*\\(?: +%s\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:%s\\)\\(?: \\|$\\)"
+ org-todo-regexp
+ org-comment-string)
+ '(9 'org-special-keyword t))
;; Blocks and meta lines
'(org-fontify-meta-lines-and-blocks
(setq org-font-lock-extra-keywords (delq nil org-font-lock-extra-keywords))
@@ -12176,17 +12178,17 @@ expands them."
(interactive)
(save-excursion
(org-back-to-heading)
-(let (case-fold-search)
- (cond
- ((looking-at (format org-heading-keyword-regexp-format
- org-comment-string))
- (goto-char (match-end 1))
- (looking-at (concat " +" org-comment-string))
- (replace-match "" t t)
- (when (eolp) (insert " ")))
- ((looking-at org-outline-regexp)
- (goto-char (match-end 0))
- (insert org-comment-string " "))
+(looking-at org-complex-heading-regexp)
+(goto-char (or (match-end 3) (match-end 2) (match-end 1)))
+(skip-chars-forward " \t")
+(unless (memq (char-before) '(?\s ?\t)) (insert " "))
+(if (org-in-commented-heading-p t)
+ (delete-region (point)
+ (progn (search-forward " " (line-end-position) 'move)
+ (skip-chars-forward " \t")
+ (point)))
+ (insert org-comment-string)
+ (unless (eolp) (insert " ")
(defvar org-last-todo-state-is-todo nil
"This is non-nil when the last TODO state change led to a TODO state.
@@ -12301,7 +12303,7 @@ When called through ELisp, arg is also interpreted in the following way:
(save-excursion
(catch 'exit
(org-back-to-heading t)
- (when (looking-at (concat "^\\*+ " org-comment-st
