Update article

This commit is contained in:
Bram Schoenmakers 2024-05-26 21:04:01 +02:00
parent 0dfe23c528
commit 97fe1bf848
Signed by: bram
GPG key ID: 0CCD19DFDC63258F
2 changed files with 12 additions and 12 deletions

View file

@ -1152,15 +1152,15 @@ Which covers my (potential) GPG/SSH usage within Emacs. Now, anytime a I perform
,#+RESULTS: ,#+RESULTS:
: \`\(?:bar\|foo\)\' : \`\(?: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: 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~). - 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: - 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. 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 org
,,#+begin_src lisp-data :tangle elfeed-scores.eld :noweb yes ,,#+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
,#+end_src ,#+end_src

View file

@ -7,15 +7,15 @@ Plain regular expressions are difficult to write and sometimes difficult to read
#+RESULTS: #+RESULTS:
: \`\(?:bar\|foo\)\' : \`\(?: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: 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~). - 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: - 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. 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 org
,#+begin_src lisp-data :tangle elfeed-scores.eld :noweb yes ,#+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
#+end_src #+end_src