Re: [O] Four issues with org-babel-tangle
> I'll write up this change as it may end up being longer than 10 lines,
> and if I write it we don't have to wait for your FSF assignment to clear
> (which can sometimes take months) before applying the patch.
That sounds good, thanks.
> In fact... if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll apply
> it immediately.
Ideally, I'd like to combine the customizable processing with the
simple fix code (which eliminates the two related bugs and the
extra *s). Something like the following in place of the corresponding
section in the patch you sent. The extra (match-end 0) and (point-min)'s
prevent those problems. Otherwise, it all looks great.
+ (funcall
+org-babel-process-comment-text
+(buffer-substring
+ (max (condition-case nil
+ (save-excursion
+(org-back-to-heading t); sets match data
+(match-end 0))
+(error (point-min)))
+ (save-excursion
+(if (re-search-backward
+ org-babel-src-block-regexp nil t)
+(match-end 0)
+ (point-min
+ (point)
I'm happy to take a look at the patch again anytime.
> Hmm, but #+tangle is not an official Org-mode directive in the same way
> that #+source:, #+headers:, and #+call: are. Unless I'm forgetting
> something #+tangle: lines would have no functional effect, in which case
> why not just use a normal org-mode comment (e.g., a line starting with
> "# ").
You're right, I agree. I'm just being particular about indentation.
I don't like to have a line starting with # when everything else is
indented.
And I don't like having to put a space after the #+ to prevent export, so I
just wanted #+tangle (or #+noop or #+comment or whatever) to count
as a non-exported comment too, just like #+ tangle would. But I can see
that it's not worth the effort or the confusion with a functional directive
that
it would cause. I'll just suck it up and use the extra space.
Thanks again, Eric.
Best,
Christopher
On Thu, Sep 15, 2011 at 18:02, Eric Schulte wrote:
> - Show quoted text -
> Christopher Genovese writes:
>
> > Hi Eric,
> >
> >Thanks for your note.
> >
> >> I would encourage you to begin the FSF assignment process if
> >> you anticipate potentially contributing more fixes in the
> >> future. Could you please send a git format-patch version of
> >> the simple fix to the list so that I might apply it?
> >
> >I will begin the FSF assignment process, and I will send a git-format
> > patch based on the simple fix. (I'll send that tonight.)
> >
>
> Fantastic.
>
> >
> >> I like the idea of introducing a customizable function for
> >> comment text transformation, however ... rather perhaps we
> >> should just leave the default value of this function as
> >> simple as possible and allow users to customize it
> >
> >That makes sense, and I like the way you did it. In particular,
> > I absolutely agree that the org-babel-trim should be removed
> > from org-babel-spec-to-string (to allow flexibility in the
> customization).
> > Making it the default processor works well, I think.
> >
> >Would you like me to submit a separate patch based on this change
> > or should I include that as part of the patch with the simple fix?
> >
>
> I'll write up this change as it may end up being longer than 10 lines,
> and if I write it we don't have to wait for your FSF assignment to clear
> (which can sometimes take months) before applying the patch.
>
> In fact... if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll apply
> it immediately.
>
>
>
> >
> >> Finally I'm not sure I fully understand what you mean by ...
> >
> > Sorry, I wasn't clear. It's a small thing. If you put
> > '#+tangle' in column 0, the line is not exported because it
> > begins with #; if you put #+ tangle on a line (spaces
> > after + and possibly before #), the line is not exported
> > because it begins with #+; but if you put #+tangle (no
> > spaces after the + but spaces before the #), the line is
> > exported. I think it would be useful if something like
> > #+tangle's (with no spaces between the # and +) were
> > *not* exported because such lines can support
> > useful customizations. Having to put the spaces after the +
> > is a bit bothersome and looks uglie
Re: [O] full parser implementation for tag queries (parentheses, fast heading match, and more)
A small addendum:
Right after I posted (of course!), I noticed both a small mistake and an
opportunity for
simplification, relating to detecting and processing the todo expressions
after a /.
Specifically, the approximate fix I proposed to the bug in the 7.8 code is
insufficient
to handle regexp matching in todo expressions. The full solution using the
new function org-find-todo-query is needed in the code as I have it, and
that can just
be plugged in instead of the string-match. (See Note h in the original
post, specifically
the string-match given there, and org-find-todo-query.)
But I realized that all that is unnecessary as the todo processing can be
easily built
into the new parser. I've mostly done that just now and will test and post
an update
Saturday, er...today.
Sorry to muddy the waters by not catching that earlier, and sorrier still
if I'm rambling.
Off to bed...
-- Christopher
On Sat, Aug 4, 2012 at 3:50 AM, Christopher Genovese wrote:
> I am writing an application layer on top of org that uses the
> entry mapping API, but I needed both negation of complex
> selections and heading searches. Because the current tag query
> parser does not handle parenthesized expressions, it does not
> allow negating complex queries. At first, I wrote a workaround
> solution that mimics/specializes the mapping API, but that
> approach seemed inelegant and harder to maintain.
>
> So instead I implemented a full parser for tag queries with a
> number of useful features (see the labeled Notes at the bottom
> for further comments on these features):
>
> 1. Parenthesized expressions to arbitrary depth are allowed.
> 2. A '-' can be used to negate a parenthesized term. [Note a]
> 3. Regex's in {} can contain braces escaped by doubling: {{ }}. [Note b]
> 4. Supports fast property search on HEADING and PRIORITY.[Note c]
> 5. Handles hyphens in property names properly. [Note
> d,h]
> 6. Allows only the proper comparison operators, including ==.[Note
> e,h]
> 7. Allows spaces around operators and terms for readability. [Note f]
> 8. Matchers use the original expression order; not a big
> deal, but free.
> 9. The error messages during parsing are reasonably helpful.
> 10. Several bug fixes and a cleaner `org-make-tags-matcher'. [Note h]
>
> I'm submitting the code for your consideration, with the
> goal of eventually incorporating this into org.el. I would be
> happy to hear any comments or suggestions you have. As I'll describe
> below, this involves relatively minor changes to two existing
> functions and adding a few new support functions. I've attached two
> files org-tag-query-parse.el (the code) and tag-query-tests.el (a
> collection of tests built on a simple framework). I've also
> put the files in http://www.stat.cmu.edu/~genovese/emacs/. The
> comments in both files will I hope be helpful.
>
> At the risk of going on too long, I'd like to add a few comments
> about the code and tests. First, the two existing functions that
> are affected in the code are `org-make-tags-matcher' and
> `org-scan-tags'. In the new version of the former, I've extracted
> out both kinds of query parsing, leading to a shorter and cleaner
> function. The new version of the latter differs in only a couple
> *very minor* places that capture two values that were already
> being computed anyway (see the diff reproduced in the comments).
> Btw, I'm working from the 7.8.11 code.
>
> Loading org-tag-query-parse.el does not change the original
> functions. Instead, I've added a `-NEW' to the names of these
> functions and saved the originals also with a `-ORIGINAL' added.
> After loading the file, you can choose a version to try by doing
>
> (org-tmp-use-tag-parser 'new)
> and
> (org-tmp-use-tag-parser 'original)
>
> or do (org-tmp-use-tag-parser) to toggle between versions.
> You can also just use the names with suffixes directly.
> I'd also suggest byte-compiling the file.
>
> I think the place to start looking at the code is the new version
> of `org-make-tags-matcher'. The main entry function for the new
> parser is `org-tag-query-parse', though the real workhorse is
> actually the function `org-tag-query-parse-1'. There is also a
> new function `org-todo-query-parse' which just extracts the
> existing todo matching method. (I didn't do anything with that
> method as the manual makes it clear that it is of secondary
> importance.) I think the modularity here makes
> `org-make-tags-matcher' and each separate parser easier to read
> and understand.
>
> The other substantial piece (in terms of lines of code)
[O] new tag query parser (re)introduction
At Bastien's urging, I'm (re)posting about my new tag query parser implementation in what I hope are clearer, more digestible, and more actionable pieces. My next few posts will be: 1. The motivating issues . 2. Some bugs/limitations in the current parser. 3. The new code and how to use/test it. [code attached] 4. A few illuminating examples. 5. A (very) brief guide to the code. I'll keep them each brief. Please let me know if you have any questions, comments, or problems. The code has been updated a bit from what I posted earlier. The test interface (separate from the main code) has one command to run all the tests and display the results nicely and a command to switch between new and original parsers to make it easier for people to try and compare them. But more on that in Part 3. Thanks for your help. Regards, Christopher
[O] new tag query parser [1/5] -- the motivating issues
My proposed changes in the tag query parser are motivated by the need and/or
desire to do the following. (The example strings work with the new parser.)
1. Combine and modify tag queries programmatically.
The leading case is that a function is given a tag query string and
needs to *exclude* lines matching that query. To do this, we can
transform query strings like so:
"foo+bar+zap/TODO" --> "-(foo+bar+zap/TODO)"
"foo|bar|zap" --> "-(foo|bar|zap)"
The key is that we want to do this programatically while still using
the mapping or agenda search command.^* I use this a lot in my GTD
layer for org; other combinations and transformations come up as well.
2. Write complex queries as simply as possible (i.e., using parens).
Parentheses aren't always necessary, but they can make things nicer.
"(xyz|{^a}-abc) & LEVEL > 1" versus "xyz&LEVEL>1|{^a}-abc&LEVEL>1"
3. Make *fast* heading and priority searches
That information is *already matched* in the current code but access
is not given (or is slow in the case of PRIORITY).
"LEVEL == 2 & HEADING <> {<.*>} & PRIORITY <> \"A\" "
4. Include braces in regular expression matches.
"+{abc\\{{3,7\\}}}" -> regex "abc\\{3,7\\}"
"{[A-Z]+\\S-+{{template}}.*$}" -> regex "[A-Z]+\\S-+{template}.*$"
Because \ escapes are used so heavily in regexex and because strings
require doubling them, using additional \'s would be messy,
ambiguous, and hard to read.
Instead, exploit that we only need to protect {}'s by *doubling*
them: {{ -> { and }} -> }. This is simple, readable, fast, and parity
makes correctness clear at a glance.^**
5. Allow spaces in query strings for readability.
Not a big deal, but easy. See the above examples
6. Get helpful error messages at parse time when there is a problem.
^* It is of course possible to create a matcher from the string
and do the search directly with lower level functions, but
that ends up being a clunky solution.
^** The doubling strategy is also familiar from the doubling of \'s
in quoted strings.
[O] new tag query parser [2/5] -- some bugs/limitations in the current parser
1. Property names with -'s are not handled properly
Specifically, the escapes are not removed.
Ex: (org-make-tags-matcher "PROP\\-WITH\\-HYPHENS=2") produces
("PROP\\-WITH\\-HYPHENS=2" and
(progn
(setq org-cached-props nil)
(=
(string-to-number
(or (org-cached-entry-get nil "PROP\\-WITH\\-HYPHENS")
""))
2))
t)
The property name in the matcher should be "PROP-WITH-HYPHENS".
The original code /does/ instead remove -'s from tag names, which
shouldn't have them anyway. I suspect that this was intended for
property names rather than tag names.
2. Incorrect comparison operators allowed, produce bad matchers.
The regular expression "[<=>]\\{1,2\\}" is used to detect the
comparison operators. But this can produce bad matchers that fail
opaquely at match time rather than giving an appropriate error
message at parse time.
Ex: (org-make-tags-matcher "P<<2") produces
("P<<2" and
(progn
(setq org-cached-props nil)
(nil
(string-to-number (or (org-cached-entry-get nil "P") "")) 2))
t)
3. A faulty test for todo matcher in org-make-tags-matcher
The current code uses (string-match "/+" match)
to detect the presence of the shortcut /!? style todo matchers.
But this is insufficient.
Ex: (org-make-tags-matcher "PROP={^\\s-*// .*$}") produces
an erroneous matcher:
("PROP={^\\s-*// .*$}" progn
(setq org-cached-props nil)
(member "PROP" tags-list))
We want to find the first slash that is not enclosed in {}'s or
""'s; if found, a todo match is needed. A simple pattern
will not be enough for this.
As a side note, org allows arbitrary characters in TODO keywords,
(For instance, both PROP={/!} and PROP="/!{/!}" are valid TODO
keywords (it works!) *and* valid property comparisons.)
The assumption of the current version is that {}'s and "'s
are excluded. I also exclude ()'s from TODO keywords in the
new version for reasons we can discuss later. Neither seems
like a big loss. If you are using {}'s, "'s, or ()'s in your
TODO keywords, use a TODO= match rather than a /!? match.
4. Regexp matchers in todo queries fail when no TODO for an item.
Ex: (org-make-tags-matcher "/{\\S-}") produces
("/{\\S-}" and t (string-match "\\S-" todo))
This will raise an error when todo is nil (no todo keyword on a
scanned item) when doing an org-map-entries, say. The todo should be
replaced with a (or todo "") as it is for tag-style TODO queries.
5. A minor consistency issue
At line 7179 in org.el (v 7.8.11), missing an org-re call in a
regex that uses posix classes. The org-re is used elsewhere,
for xemacs compatibility, I think.
[FWIW, all of these are problems eliminated or made moot in the new parser.]
[O] new tag query parser [4/5] -- a few ``illuminating'' examples
#+TITLE: New Tag Query Parser: A Few Illuminating Examples
This post is structured as an org file with the example commands listed
within.
Copy this to a buffer and try the commands below on that buffer.
* Preliminaries Point 207
The Point # labels on the headings give the point values for the
beginning of the heading. To make this accurate, we need to
standardize tag placemnet. Using M-: or equivalent means,
execute the following in this buffer:
#+begin_src emacs-lisp
(set (make-local-variable 'org-tags-column) -80)
(set (make-local-variable 'org-todo-keywords)
'((sequence "TODO" "WAIT" "DONE")))
#+end_src
If necessary, do C-u C-c on a headline to realign the tags.
* Parenthesized Expressions Point 714
:feature:
Fully parenthesized expressions are allowed in the tag query strings.
A - selector before the parenthesized expression acts as a logical
not. These expressions can include an old-style /!? todo-query string
as well, which extends to the closing paren.
** TODO Paren Examples Point 1057
:example:paren:
+ (org-map-entries 'point "(example&HEADING={^Paren}/TODO)")
+ (org-map-entries 'point "HEADING={Paren} & -(extra | LEVEL = 1)")
+ (org-map-entries 'point "(feature | LEVEL == 2)({^p}/WAIT|TODO)")
The first two should give 1057, the third (1057 1492).
* Another Point 1411
:extra:
** WAIT This is not a feature example Point 1492
:pretend:
** We can manipulate and combine whole expressions Point 1573
+ (org-map-entries 'point "-(feature&LEVEL=2)")
+ (org-map-entries 'point "-(feature|LEVEL==2)|{^$}")
Note that inheritance can affects the tag matches; it might
be nice to be able to distinguish this in searches.
Note also that the original matcher fails silently here.
* Braces and Spaces AAA Point 1921
:feature:
** DONE Just a marker AA Point 2002
** TODO Simple Examples Point 2042
:example:syntax:
+ (org-map-entries 'point "example & TODO <> \"DONE\")
+ (org-map-entries 'point "example/!")
+ (org-map-entries 'point "example | HEADING = { A\\{{3,4\\}}[^A]}")
+ Allows = or == for equality operator.
** [#A] Ok Point 2338
** [#B] This is fast Point 2360
+ (org-map-entries 'point "PRIORITY=\"B\"")
Many more examples are available in the test suite. Do C-u M-x
run-tag-query-tests
to see them.
[O] new tag query parser [5/5] -- a (very) brief guide to the code
A few comments that might help navigate the new parser code in
org-tag-query-parse.el. All diffs are relative to the 7.8.11 org.el.
Let me know if you have any questions.
* High Level Changes
Two existing org functions are altered:
1. org-make-tags-matcher
2. org-scan-tags
The changes to the latter are minor, only defining two new
let-bindings to capture information already grabbed, and a slightly
modified regex. A unified diff between the new and old org-scan-tags
is given in the comments preceding the function in the new code.
* Low Level Entry Points
1. org-tag-query-parse -- the workhorse function
2. org-todo-query-parse -- handles /!? style todo components
Tag style and /!? todo style queries are handled in a unified way;
org-tag-query-parse delegates the latter to org-todo-query-parse but
manages the overall parsing. Note that /!? style matches must either
end the query string or end the current parenthesized expression. For
instance, "-(foo+bar/!{^T}-TODO)|LEVEL==5" is a valid query.
* Utilities
1. org-match-cond
2. org-read-balanced-string
3. org-read-quoted-string-in-query
4. org-tquery-error
5. org-defhash-at-compile
The first is a macro that lets the parser be expressed in very
readable terms. It does much of its work at compile-time, and produces
code that is optimized in several ways. This makes it beneficial to
byte-compile org-tag-query-parse.el.
The second and third parse delimited strings, the first with
balanced delimiters and doubling for escape, the second using
standard string semantics.
The fourth handles errors, giving useful information in messages.
The fifth is a macro that makes it pleasant to define literal
hash tables that will be defined at both compile and load time.
See examples of use in the code.
Re: [O] full parser implementation for tag queries (parentheses, fast heading match, and more)
Hi Samuel,
Thanks for your note. Just FYI, the earlier parser code in this thread
has
been superseded by the code in the post "new tag query parser [3/5]".
The sexp input is a nice idea, and it would be very easy I think.
The function org-make-tags-matcher now takes a query string
but could easily be modified to operate on a form as well.
I've included some code below that basically does the job. It defines a
function
`mtrans' that transforms a sexp representation into a matcher. It can
certainly be
better optimized (and fully tested), but I think it would do just what you
want
if inserted in org-make-tags-matcher. (Note: The car of the matcher is the
query string,
for reasons that aren't entirely clear. Because this is dropped anyway in
practice,
I don't bother making it accurate in this code. As such, I'll just give the
cdr in the examples below.)
A few examples follow to give the idea and show the results. It seems
to handle
all the cases nicely. In the sexp representation, strings stand for exact
string matches
and both [] and (re ) stand for regex matches, with
symbols
for properties and standard boolean and comparison ops in the form.
The keyword :todo-only acts like /! in the query strings, and = and <> also
allow arbitrary lisp code for the property comparison with equal (as long
as the
form does not start with or, and, not, or re but then it can be shielded
with (identity ...)).
I then append the code, which is also attached. I see no problems
with adding this to org-make-tags-matcher and would be interested in other
opinions.
Best,
Christopher
;;; Examples
(mtrans "foo") ; corresponds to query string "foo"
=> (member "foo" tags-list)
(mtrans ["^f"]) ; or (mtrans '(re "^f")) corresponds to query string
"{^f}"
=> (progn
(setq org-cached-props nil)
(org-match-any-p "^f" tags-list))
(mtrans '(and "foo" (not "bar") (re "^u.*v"))) ; query string
"foo-bar+{^u.*v}
=> (progn
(setq org-cached-props nil)
(and
(member "foo" tags-list)
(not (member "bar" tags-list))
(org-match-any-p "^u.*v" tags-list)))
(mtrans '(or (and "xyz" (= TODO ["^T"]) ["u\\{2,4\\}"] (<= LEVEL 3))
(> APROP "foo")
(and (= BPROP 4) (<> HEADING "ignore"
; query string
"xyz+TODO={^T}+{u\\{{2,4\\}}}+LEVEL<=3 | APROP > \"foo\" | BPROP=4&HEADING
<> \"ignore\""
=> (progn
(setq org-cached-props nil)
(or
(and
(member "xyz" tags-list)
(org-string-match= (or todo "") "^T")
(org-match-any-p "u\\{2,4\\}" tags-list)
(<= level 3))
(org-string> (or (org-cached-entry-get nil "APROP") "") "foo")
(and
(= (org-cached-entry-get nil "BPROP") 4)
(org-string<> (or heading "") "ignore"
(mtrans '(or (and "foo" (not "bar") ["^u.*v"] (> LEVEL 2))
(= APROP "foo")
(and (= BPROP ["/.*/"]) (<> BPROP "/ignore/"))
(<> TODO "TODO")
(> SCHEDULED "<2008-11-12>")))
; query string "foo-bar+{^u.*v}+LEVEL>2 | APROP=\"foo\"|
BPROP={/.*/} & BPROP <> "/ignore/" | TODO<>\"TODO\" | SCHEDULED >
\"<2008-11-12>\""
=> (progn
(setq org-cached-props nil)
(or
(and
(member "foo" tags-list)
(not (member "bar" tags-list))
(org-match-any-p "^u.*v" tags-list)
(> level 2))
(string= (or (org-cached-entry-get nil "APROP") "") "foo")
(and
(org-string-match= (or (org-cached-entry-get nil "BPROP") "")
"/.*/")
(org-string<> (or (org-cached-entry-get nil "BPROP") "")
"/ignore/"))
(org-string<> (or todo "") "TODO")
(org-time> (or (org-cached-entry-get nil "SCHEDULED") "")
1226466000.0)))
(mtrans '(and :todo-only
(or (and (not ["^abc"]) ["ex"] (= A_PROP "foo"))
(>= B_PROP 1.2e10)
(and (< D_PROP "<2008-12-24 18:30>") (= FOO (call other
lisp code here))
; except for FOO part which has no analogue, query string
"-{^abc}+{ex}&A_PROP=\"foo\" | B_PROP > 1.2e10 | DROP < \"<2008-12-24
18:30>\" & FOO = ..."
=> (progn
(setq org-cached-props nil)
(and
(member todo org-not-done-keywords)
(or
(and
(not (org-match-any-p "^abc" tags-list))
(org-match-any-p "ex" tags-list)
(string= (or (org-cached-entry-get nil "A_PROP") "") "foo"))
(>= (org-cached-entry-get nil "B_PROP") 120.0)
(and
(org-time< (or (org-cached-entry-get nil "D_PROP") "")
1230094800.0)
(equal (org-cached-entry-get nil "FOO") (call other lisp code
here))
;;; The Code
(eval-when-compile (require 'cl))
(defun mtrans (matcher-sexp)
"Create a tag/todo matcher from a sexp representation.
In the sexp representation, components are transformed as follows:
+ A literal string becomes an exact tag match.
+ A [] or (re )
Re: [O] new tag query parser [1/5] -- the motivating issues
Hi Martin,
Assuming that org.el (with the new parser code) is byte-compiled, the
performance
difference is very minor. The only difference comes in converting the query
string
to a matcher form. The new parser has some additional overhead in function
calls and
keeping track of state, but in practice it is negligible.
For example, in some basic benchmarks, both parsers can convert 10,000
fairly
complex query strings in a second or two *total*. If you run the tests,
you'll see that it does
over 200 cases plus comparisons and a good deal of other stuff in a blink
of an eye.
So for any given agenda search or entry mapping, users will not notice
any real difference.
Regarding backward compatibility, there is no conversion necessary. All
currently
valid queries produce equivalent matchers with the new code. The new parser
extends
the grammar to incorporate features that would not produce valid matchers
with current
code: parenthesized expressions, spaces, and {}-escapes in regexp matches.
The only issue in this regard is that I added the name HEADING
to the list of special properties (like LEVEL, CATEGORY, PRIORITY, etc.).
This allows heading matches, which is one of my favorite features. So
existing
queries with a user-defined property HEADING would match the real heading
rather
than the property. This seems like a minor issue to me, but it would need
to be noted.
Regards,
Christopher
P.S. The provision above (and in the original posts) about byte compiling
the
parser code (which would be in org.el) relates to macro-expansion overhead.
I use a macro that makes the new parser function more readable and
maintainable,
and does much of its work at compile time to produce faster code.
In interpreted code that macro is expanded each pass through the loop.
The macro could be eliminated if necessary, or made faster in interpreted
code by
various tricks (that would add some overhead to compiled code).
But since org.el is typically byte compiled during installation, this
doesn't seem
to me to be a problem. Performance is fine in practice either way, though
faster in
the typical compiled case, and I think the clarity gained from the macro is
worthwhile.
But definitely byte compile the new code before testing, as I advise in the
posts.
On Sat, Aug 18, 2012 at 10:18 AM, Martin Pohlack
wrote:
> Hi Christopher,
>
> If I understand your descriptions correctly, your proposed changes are
> very cool.
>
> Could you elaborate a little bit on performance?
>
> * Are we going to see speedups? In what cases? How much?
>
> * If we lose performance, could you quantify that a bit with some examples?
>
> A question regarding backwards compatibility (I might have missed that
> in the description, sorry): Are you converting existing queries on the
> fly each time, or do we have to convert our queries once? If yes, is
> there some assisting code?
>
> Thanks,
> Martin
>
>
[O] Tangling does not detect src blocks with capital BEGIN_SRC/END_SRC when case-fold-search nil
When tangling a file whose source code blocks have capitalized BEGIN_SRC and END_SRC (as produced by
[Orgmode] org-write-agenda failure
On Mac OS X 10.5.8, GNU Emacs 23.2.1, Org Mode 7.4,
setting the following:
(setq org-todo-keywords
'((sequence "TODO" "WAIT" "DONE")))
(setq org-todo-keyword-faces '(("WAIT" . "lightgoldenrod2")))
has the intended effect, with WAIT items properly displayed, ... *until*
I do org-write-agenda in the Agenda buffer (writing to "foobar.pdf"),
which fails in ps-print with the stack trace shown below.
(The failure is not dependent on the color chosen in the string.)
Note, however, that when doing the following instead
everything works:
(setq org-todo-keywords
'((sequence "TODO" "WAIT" "DONE")))
(copy-face 'org-todo 'org-wait-face) ; bug with string when doing
org-write-agenda
(set-face-foreground 'org-wait-face "lightgoldenrod2")
(setq org-todo-keyword-faces '(("WAIT" . org-wait-face)))
In the former case (which fails), the problem appears in the call
(ps-face-attribute-list '(:inherit org-todo :foreground
"lightgoldenrod2"))
but if the property list is itself wrapped in a list as
(ps-face-attribute-list '((:inherit org-todo :foreground
"lightgoldenrod2")))
then this function does not raise an error.
This seems like a bug to me, as I'm pretty sure I'm matching the
documented form required for org-todo-keyword-faces (in both cases),
but I could be wrong. I have not had a chance to track this down all the
way, but I thought I'd
pass it on in hopes it is either helpful or will help someone show me the
error of my ways.
Thanks for your help. The backtrace for the original problem is given below.
Debugger entered--Lisp error: (wrong-type-argument listp
"lightgoldenrod2")
ps-face-attributes("lightgoldenrod2")
ps-face-attribute-list((:inherit org-todo :foreground
"lightgoldenrod2"))
ps-plot-with-face(662 666 (:inherit org-todo :foreground
"lightgoldenrod2"))
ps-generate-postscript-with-faces1(1 1549)
ps-generate-postscript-with-faces(1 1549)
ps-generate(# 1 1549
ps-generate-postscript-with-faces)
ps-spool-with-faces(1 1549 nil)
ps-print-with-faces(1 1549 "~/foobar.ps")
ps-print-buffer-with-faces("~/foobar.ps")
(cond ((org-bound-and-true-p org-mobile-creating-agendas)
(org-mobile-write-agenda-for-mobile file)) ((string-match "\\.html?\\'"
file) (require ...) (set-buffer ...) (when ... ... ... ...) (write-file
file) (kill-buffer ...) (message "HTML written to %s" file)) ((string-match
"\\.ps\\'" file) (require ...) (ps-print-buffer-with-faces file) (message
"Postscript written to %s" file)) ((string-match "\\.pdf\\'" file) (require
...) (ps-print-buffer-with-faces ...) (call-process "ps2pdf" nil nil nil ...
...) (delete-file ...) (message "PDF written to %s" file)) ((string-match
"\\.ics\\'" file) (require ...) (let ... ...)) (t (let ... ... ... ... ...
... ...)))
(progn (rename-buffer "Agenda View" t) (set-buffer-modified-p nil)
(insert bs) (org-agenda-remove-marked-text (quote org-filtered)) (while
(setq beg ...) (delete-region beg ...)) (run-hooks (quote
org-agenda-before-write-hook)) (cond (... ...) (... ... ... ... ... ... ...)
(... ... ... ...) (... ... ... ... ... ...) (... ... ...) (t ...)))
(unwind-protect (progn (rename-buffer "Agenda View" t)
(set-buffer-modified-p nil) (insert bs) (org-agenda-remove-marked-text ...)
(while ... ...) (run-hooks ...) (cond ... ... ... ... ... ...)) (and
(buffer-name temp-buffer) (kill-buffer temp-buffer)))
(save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
... ... ... ... ... ... ...) (and ... ...)))
(with-current-buffer temp-buffer (unwind-protect (progn ... ... ...
... ... ... ...) (and ... ...)))
(let ((temp-buffer ...)) (with-current-buffer temp-buffer
(unwind-protect ... ...)))
(with-temp-buffer (rename-buffer "Agenda View" t)
(set-buffer-modified-p nil) (insert bs) (org-agenda-remove-marked-text
(quote org-filtered)) (while (setq beg ...) (delete-region beg ...))
(run-hooks (quote org-agenda-before-write-hook)) (cond (... ...) (... ...
... ... ... ... ...) (... ... ... ...) (... ... ... ... ... ...) (... ...
...) (t ...)))
(let ((bs ...) beg) (org-agenda-unmark-filtered-text)
(with-temp-buffer (rename-buffer "Agenda View" t) (set-buffer-modified-p
nil) (insert bs) (org-agenda-remove-marked-text ...) (while ... ...)
(run-hooks ...) (cond ... ... ... ... ... ...)))
(save-window-excursion (org-agenda-mark-filtered-text) (let (...
beg) (org-agenda-unmark-filtered-text) (with-temp-buffer ... ... ... ... ...
... ...)))
(save-excursion (save-window-excursion
(org-agenda-mark-filtered-text) (let ... ... ...)))
(let nil (save-excursion (save-window-excursion ... ...)) #)
eval((let nil (save-excursion (save-window-excursion ... ...))
#))
org-let(nil (save-excursion (save-window-excursion
(org-agenda-mark-filtered-text) (let ... ... ...))) #)
org-write-agenda("~/foobar.pdf")
___
Emacs-orgmode mailing l
