Rasmus <[email protected]> writes:
> I /think/ that is what I would like. But I don't understand the what you
> mean concretely: would you have something like:
>
> (:subject "SUBJECT" nil nil space parsed)
(:subject "SUBJECT" nil nil parsed)
`parsed' behavior implies `space' anyway, since we're talking about
secondary strings.
Basically,
(plist-get info :subject)
would return the same as the following, currently,
(org-element-parse-secondary-string
(plist-get info :subject) (org-element-restriction 'keyword))
> I agree this is a difficult problem. Personally, I think it is fine to
> consider a keyword as a keyword and nothing more, and not consider content
> within a keyword. However, as I recall, John had a post a while back
> about mapping over bold in CAPTIONS or something like that.
`org-element-map' can find objects in captions, with an optional
argument.
> I think it may be a mess to interpret content of a keyword at
> org-element-map level. Consider if #+SUBJECT is interpreted with in
> ox-koma-letter but not in an imaginary ox-new-letter. Would it not be
> confusing?
I think so.
Regards,
