unpackaged/lorem-ipsum-overlay: exception list with Org keywords
Closed this issue ยท 6 comments
Hi,
Awesome function!
Would you be so kind to implement a list of words that is not getting replaced? I'm thinking of the Org keywords (TODO, NEXT, STARTED, DONE, SCHEDULED, :PROPERTIES:, ...) as well as some user-defined words (Important, Priorities, Today, ...).
For example, my Org agenda does not look good because every word got replaced including keywords as well as org-super-agenda headings. With a user-defined blacklist, I could define exceptions to the replacement rule.
Hi Karl,
Well, that was more difficult than I expected (due to needing to compare regexps against one thing but replace a different part, and to comparing the configured regexps against part of what's matched by the main one), but this seems to work. Please let me know if it works for you.
@emacsomancer You may find this interesting as well.
Thanks @alphapapa for adding this! Very much appreciated.
Unfortunately, my lack of elisp is taking its toll (again).
I tried:
(setq unpackaged/lorem-ipsum-overlay-exclude
'(
"NEXT" "TODO" "STARTED" "WAITING" "DONE" "SOMEDAY" "CANCELED"
"Today"
"Important" "Priority" "Started" "WAITING items" (rx "Other" space "items") "reward" "Sched." "Scheduled:"
"Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" "Sunday"
"January" "February" "March" "April" "May" "June" "July" "August" "September" "October" "November" "November" "December"
)
)
When I omit the (rx ...)
part, the fixed keywords that do not contain spaces are ignored on replacement, thus working fine. However, when I try to add phrases with spaces using the rx
part I don't get yet. I also tried `(rx ...)
.
rx
is a macro. You quoted the list containing its form, so it is not expanded. If you want to use rx
, you'll have to backquote the list and unquote the rx
form, like:
(setq unpackaged/lorem-ipsum-overlay-exclude
`(
"NEXT" "TODO" "STARTED" "WAITING" "DONE" "SOMEDAY" "CANCELED"
"Today"
"Important" "Priority" "Started" "WAITING items" ,(rx "Other" space "items") "reward" "Sched." "Scheduled:"
"Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" "Sunday"
"January" "February" "March" "April" "May" "June" "July" "August" "September" "October" "November" "November" "December"
)
)
Note as well that these are regexps, so metacharacters like .
in "Sched."
will not match literally.
Be sure to C-h f rx RET
, it's very powerful.
Hi,
Thanks for pointing me to rx
. This seems to be a very cool method to define maintainable RegEx.
The quoting now works and now I understand what I did wrong. However, I still have issues with expressions that are not single words: (I only tried to fix "Other items" and "Sched.10x:" so far)
(setq unpackaged/lorem-ipsum-overlay-exclude
`(
"NEXT" "TODO" "STARTED" "WAITING" "DONE" "SOMEDAY" "CANCELED"
"Today"
"Important" "Started" "reward" "Scheduled:"
,(rx "Other" space "items") ;; "Other items" NOT working yet
,(rx "Sched" punct (one-or-more digit) "x:") ;; "Sched.10x:" NOT working yet
"WAITING items" ;; "WAITING items" NOT working yet
"Priority <= B items" ;; "Priority <= B items" NOT working yet
"misc" "projects" "issues" "hardware"
"Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" "Sunday"
"January" "February" "March" "April" "May" "June" "July" "August" "September" "October" "November" "November" "December"
)
)
What is it that I still don't get? When I try them with re-builder
and switch to rx
syntax, they work!
For example, '(seq "Sched" punct (one-or-more digit) "x:")
is matching in the re-builder
but not when used in the unpackaged/lorem-ipsum-overlay-exclude
above.
When I take a look at unpackaged/lorem-ipsum-overlay-exclude
, they result in: "Other[[:space:]]items" "Sched[[:punct:]][[:digit:]]+x:"
which seems OK to me. Is there an issue with spaces also within regex?
Like I said, it's kind of complicated the way these regexps interact, and the way non-whitespace tokens are matched against while only replacing alphabetic characters. I can see how it would be helpful to have the ability to match spaces, and there's probably some way we could write the code differently to handle this. I'll be glad to consider patches to that effect. But the code is slow enough on a large buffer as it is, and it was complicated enough to get to this point, so I don't want to mess with it further myself. In the meantime, I think we should define that regexps defined in this variable should not contain whitespace.
I see. Fair enough. Thanks for the code adaption. Maybe you'll like to add my example (without the non-working lines) in the docu string.