org-log-note-headings 'state

org-log-note-headings 'state

[John J Foerch]

Hello,

I'm writing an extension for org-mode wherein it would be incredibly
convenient to be able to parse the state changes inside of LOGBOOK
drawers to get the state-names and timestamps.  However, I find that
state changes are currently only parsable in an ad hoc manner, as for
example by org-agenda-log-mode.  The docsting of org-log-note-headings
mentions this:

  "In fact, it is not a good idea to change the `state' entry, because
  agenda log mode depends on the format of these entries."

It is disappointing to me that the state entry of org-log-note-headings
is not safely user-configurable because of this.  Personally, I do like
to configure it to something a little cleaner and easier to read,
("State -> %s  %d").  (I haven't yet used org-agenda-log-mode, so haven't
run into the problems warned of in the docstring.)  If I were to do ad
hoc parsing of state changes in the mode I'm writing, I would have to
give up my local configuration of the state entry of org-log-note-headings.

These thoughts lead me to suggest that maybe org-log-note-headings is no
longer sufficient to its original purpose, because extensions wish to
parse state changes, but that blocks users from configuring the formats.
Perhaps it is time to replace it with something that guarantees ability
to parse.

Thoughts?

-- 
John Foerch

Re: org-log-note-headings 'state

[Bastien]

Hi John,

John J Foerch <jjfoerch@earthlink.net> writes:

> These thoughts lead me to suggest that maybe org-log-note-headings is no
> longer sufficient to its original purpose, because extensions wish to
> parse state changes, but that blocks users from configuring the formats.
> Perhaps it is time to replace it with something that guarantees ability
> to parse.

I see the problem -- what do you suggest as a useful replacement for
`org-log-note-headings'? 

> Thoughts?

I understand your point but I need more arguments to spend time on 
improving this.  "Argument" = code that we would like to run and that
would need a rewrite of `org-log-note-headings'.

Thanks!

-- 
 Bastien

Re: org-log-note-headings 'state

[John J Foerch]

Bastien <bzg@gnu.org> writes:
> Hi John,
>
> John J Foerch <jjfoerch@earthlink.net> writes:
>
>> These thoughts lead me to suggest that maybe org-log-note-headings is no
>> longer sufficient to its original purpose, because extensions wish to
>> parse state changes, but that blocks users from configuring the formats.
>> Perhaps it is time to replace it with something that guarantees ability
>> to parse.
>
> I see the problem -- what do you suggest as a useful replacement for
> `org-log-note-headings'? 
>
>> Thoughts?
>
> I understand your point but I need more arguments to spend time on 
> improving this.  "Argument" = code that we would like to run and that
> would need a rewrite of `org-log-note-headings'.
>
> Thanks!

I have been experimenting with parsing the format-string to build a
regexp to match the generated-strings.  This approach depends upon the
parsability of the expansions of each of the percent-codes.  As concerns
org-log-note-headings, %t, %T, %d, %D, %s, %S, and %u all have parseable
expansions, as far as I can tell.  I'm not sure about %U, but if the
rest of the string is not too complicated, it shouldn't be a problem.
Format-code flag, width, and precision add some complexity to the
problem of generating regexps to match the codes, and I haven't done
that bit yet.  Overall I think this could be a very viable approach, and
I'll paste my scraps of code below:

;;; parsing state changes
;;;
(defun org-split-format-string (str)
  (let ((case-fold-search t)
        (format-regexp "%[+ #-0]*[0-9]*\\(\\.[0-9]+\\)?[%a-z]")
        (parts (list))
        (s 0))
    (while (string-match format-regexp str s)
      (let* ((beg (match-beginning 0))
             (end (match-end 0))
             (before (substring str s beg)))
        (unless (string= before "")
          (push before parts))
        (push (substring str beg end) parts)
        (setq s end)))
    (let ((last (substring str s)))
      (unless (string= last "")
        (push last parts)))
    (nreverse parts)))

;;tests
(equal (org-split-format-string "CLOSING NOTE %t") '("CLOSING NOTE " "%t"))
(equal (org-split-format-string "State %-12s from %-12S %t") '("State " "%-12s" " from " "%-12S" " " "%t"))
(equal (org-split-format-string "foo %t bar") '("foo " "%t" " bar"))
(equal (org-split-format-string "foo") '("foo"))
(equal (org-split-format-string "%s") '("%s"))
(equal (org-split-format-string "%s%t") '("%s" "%t"))

(defun org-get-format-parser (f)
  (let ((format-regexp "^%\\([+ #-0]*\\)\\([0-9]*\\)\\(\\.[0-9]+\\)?\\([%a-z]\\)$"))
    (string-match format-regexp f)
    (let ((flag (match-string 1 f))
          (numb (match-string 2 f))
          (prec (match-string 3 f))
          (code (match-string 4 f)))
      (cond
        ;; hardcode format codes for now.. later, pass them in as an
        ;; alist or something.
        ((string= "t" code) "\\(\\[.*?\\]\\)") ;; inactive timestamp
        ((string= "T" code) "\\(<.*?>\\)")     ;;   active timestamp
        ((string= "d" code) "\\(\\[.*?\\]\\)") ;; inactive short-format timestamp
        ((string= "D" code) "\\(<.*?>\\)")     ;;   active short-format timestamp
        ((string= "s" code) "\\(\".*?\"\\)")   ;; new TODO state
        ((string= "S" code) "\\(\".*?\"\\)")   ;; old TODO state
        ((string= "u" code) "\\(\\w+\\)") ;; user name
        ((string= "U" code) "\\(.*\\)") ;; full user name
        (t (error "Unsupported format: %s" f))))))

(defun org-parse-formatted-text (fmt str)
  (let* ((sfmt (org-split-format-string fmt))
         (regexp (concat
                  "^"
                  (apply
                   'concat
                   (mapcar
                    (lambda (x)
                      (if (equal ?% (aref x 0))
                          (org-get-format-parser x)
                          (regexp-quote x)))
                    sfmt))
                  "$")))
    regexp))

;; (org-parse-formatted-text "State %-12s from %-12S %t" "")
;; => "^State \\(\".*?\"\\) from \\(\".*?\"\\) \\(\\[.*?\\]\\)$"

;;;
;;; end parsing state changes

Thank you

-- 
John Foerch

Re: org-log-note-headings 'state

[Ilya Shlyakhter]

On 3/27/2012 9:49 PM, John J Foerch wrote:
>>> These thoughts lead me to suggest that maybe org-log-note-headings is no
>>> longer sufficient to its original purpose, because extensions wish to
>>> parse state changes, but that blocks users from configuring the formats.
>>> Perhaps it is time to replace it with something that guarantees ability
>>> to parse.
> I have been experimenting with parsing the format-string to build a
> regexp to match the generated-strings.  This approach depends upon the
> parsability of the expansions of each of the percent-codes.  As concerns
> org-log-note-headings, %t, %T, %d, %D, %s, %S, and %u all have parseable
> expansions, as far as I can tell.  I'm not sure about %U, but if the
> rest of the string is not too complicated, it shouldn't be a problem.
> Format-code flag, width, and precision add some complexity to the
> problem of generating regexps to match the codes, and I haven't done
> that bit yet.  Overall I think this could be a very viable approach, and
> I'll paste my scraps of code below:
>
> ;;; parsing state changes
> ;;;

Thanks a lot -- I also need the ability to parse state changes for an 
extension I am writing.  It'll be very useful if you could post the
final working version of your patch for this.

thanks,

ilya

Re: org-log-note-headings 'state

[John J Foerch]

Ilya Shlyakhter <ilya_shl@alum.mit.edu> writes:
> On 3/27/2012 9:49 PM, John J Foerch wrote:
>>>> These thoughts lead me to suggest that maybe org-log-note-headings is no
>>>> longer sufficient to its original purpose, because extensions wish to
>>>> parse state changes, but that blocks users from configuring the formats.
>>>> Perhaps it is time to replace it with something that guarantees ability
>>>> to parse.
>> I have been experimenting with parsing the format-string to build a
>> regexp to match the generated-strings.  This approach depends upon the
>> parsability of the expansions of each of the percent-codes.  As concerns
>> org-log-note-headings, %t, %T, %d, %D, %s, %S, and %u all have parseable
>> expansions, as far as I can tell.  I'm not sure about %U, but if the
>> rest of the string is not too complicated, it shouldn't be a problem.
>> Format-code flag, width, and precision add some complexity to the
>> problem of generating regexps to match the codes, and I haven't done
>> that bit yet.  Overall I think this could be a very viable approach, and
>> I'll paste my scraps of code below:
>>
>> ;;; parsing state changes
>> ;;;
>
> Thanks a lot -- I also need the ability to parse state changes for an
> extension I am writing.  It'll be very useful if you could post the
> final working version of your patch for this.
>
> thanks,
>
> ilya

Will do.

-- 
John Foerch