Update article
This commit is contained in:
parent
0dfe23c528
commit
97fe1bf848
2 changed files with 12 additions and 12 deletions
12
gists.org
12
gists.org
|
@ -1152,15 +1152,15 @@ Which covers my (potential) GPG/SSH usage within Emacs. Now, anytime a I perform
|
|||
,#+RESULTS:
|
||||
: \`\(?:bar\|foo\)\'
|
||||
|
||||
It's not only more readable (in my opinion), but it's also easier to construct with all the Lisp writing tools that can be used within Emacs (e.g. paredit or puni).
|
||||
It's not only more readable (in my opinion), but it's also easier to edit with all the Lisp writing tools that can be used within Emacs (e.g. [[https://paredit.org/][paredit]] or [[https://github.com/AmaiKinono/puni][puni]]).
|
||||
|
||||
However, using =rx= is not always possible. Lisp data files may contain regular expressions but they are treated as data and not as executable code.
|
||||
However, using the =rx= macro is not always possible. Lisp data files may contain regular expressions, but they are treated as data and not as executable code.
|
||||
|
||||
One prime example is elfeed-score: an Emacs package that allows you to write scoring rules for elfeed entries. Scoring rules are defined with an Lisp data file, and a rule may allow regular expressions but they have to be written out verbatim.
|
||||
One prime example is [[https://www.unwoundstack.com/doc/elfeed-score/][elfeed-score]]: an Emacs package that allows you to write scoring rules for elfeed entries. Scoring rules are defined with an Lisp data file, and a rule may allow regular expressions but they have to be written out verbatim.
|
||||
|
||||
Luckily there's a work-around with Org Mode:
|
||||
|
||||
- Write the scoring rules in an =lisp-data= source block.
|
||||
- Write the scoring rules in an =lisp-data= source block (see below).
|
||||
- Tangle the file to a location that is read by the elfeed-score package (see variable ~elfeed-score-score-file~).
|
||||
- For the regular expression we use a small =elisp= block as follows:
|
||||
|
||||
|
@ -1173,11 +1173,11 @@ Which covers my (potential) GPG/SSH usage within Emacs. Now, anytime a I perform
|
|||
|
||||
It accepts an /expression/ that is a Lisp form that =rx= accepts. It is converted to a string, surrounded by quotes and since we use it in a Lisp string, backslashes should be doubled.
|
||||
|
||||
- By naming the source block =rx= we can call it from other source blocks:
|
||||
- By naming the source block =rx= we can call it from other source blocks using noweb expansion:
|
||||
|
||||
,#+begin_src org
|
||||
,,#+begin_src lisp-data :tangle elfeed-scores.eld :noweb yes
|
||||
(("title" (:text <<rx '(or "foo" "bar")>> :value 1 :type r)))
|
||||
(("title" (:text <<rx('(or "foo" "bar"))>> :value 1 :type r)))
|
||||
,,#+end_src
|
||||
,#+end_src
|
||||
|
||||
|
|
|
@ -7,15 +7,15 @@ Plain regular expressions are difficult to write and sometimes difficult to read
|
|||
#+RESULTS:
|
||||
: \`\(?:bar\|foo\)\'
|
||||
|
||||
It's not only more readable (in my opinion), but it's also easier to construct with all the Lisp writing tools that can be used within Emacs (e.g. paredit or puni).
|
||||
It's not only more readable (in my opinion), but it's also easier to edit with all the Lisp writing tools that can be used within Emacs (e.g. [[https://paredit.org/][paredit]] or [[https://github.com/AmaiKinono/puni][puni]]).
|
||||
|
||||
However, using =rx= is not always possible. Lisp data files may contain regular expressions but they are treated as data and not as executable code.
|
||||
However, using the =rx= macro is not always possible. Lisp data files may contain regular expressions, but they are treated as data and not as executable code.
|
||||
|
||||
One prime example is elfeed-score: an Emacs package that allows you to write scoring rules for elfeed entries. Scoring rules are defined with an Lisp data file, and a rule may allow regular expressions but they have to be written out verbatim.
|
||||
One prime example is [[https://www.unwoundstack.com/doc/elfeed-score/][elfeed-score]]: an Emacs package that allows you to write scoring rules for elfeed entries. Scoring rules are defined with an Lisp data file, and a rule may allow regular expressions but they have to be written out verbatim.
|
||||
|
||||
Luckily there's a work-around with Org Mode:
|
||||
|
||||
- Write the scoring rules in an =lisp-data= source block.
|
||||
- Write the scoring rules in an =lisp-data= source block (see below).
|
||||
- Tangle the file to a location that is read by the elfeed-score package (see variable ~elfeed-score-score-file~).
|
||||
- For the regular expression we use a small =elisp= block as follows:
|
||||
|
||||
|
@ -28,11 +28,11 @@ Luckily there's a work-around with Org Mode:
|
|||
|
||||
It accepts an /expression/ that is a Lisp form that =rx= accepts. It is converted to a string, surrounded by quotes and since we use it in a Lisp string, backslashes should be doubled.
|
||||
|
||||
- By naming the source block =rx= we can call it from other source blocks:
|
||||
- By naming the source block =rx= we can call it from other source blocks using noweb expansion:
|
||||
|
||||
#+begin_src org
|
||||
,#+begin_src lisp-data :tangle elfeed-scores.eld :noweb yes
|
||||
(("title" (:text <<rx '(or "foo" "bar")>> :value 1 :type r)))
|
||||
(("title" (:text <<rx('(or "foo" "bar"))>> :value 1 :type r)))
|
||||
,#+end_src
|
||||
#+end_src
|
||||
|
||||
|
|
Loading…
Reference in a new issue