> I was expecting that Arthur would come up with a preprocessor written > in (I guess) 30 lines of Elisp... Interesting 🙂. If you have red my previous mails to this list you might have noticed that I am not an elisp guru. Stefan has outlined two possible ways how this could be implemented in Elisp, if you follow his advice I am sure you will have a working solution you can present to us. I don't care how many lines of code it will take. > a lot of people would like to play > with it, add tests, modify it, and so on You still can my friend, and I encourage you to do and test if the idea itself is valid. That was the purpose why I wrote patch. I clearly stated it is just a prototype of an idea in order to test the soundness of the idea. It takes two minutes to patch 3 files and rebuild Emacs. if you wish to play with it. It is not like it cost some enormous mount of money or labour. > and we could use it to > earn how to create our own preprocessors. There are many sources in Emacs source code or elsewhere you can look at if you need learning material. >A preprocessor written as patch to the C source of Emacs feels useless >to me. The patch is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. 🙂 [[]], Eduardo Ochs http://angg.twu.net/#eev http://angg.twu.net/emacsconf2019.html On Fri, 20 Dec 2019 at 13:18, Stefan Monnier > wrote: > I really understand the concern, but I must ask how would one change the > elisp itself without re-implementing much or some of of elisp parser if it would > be done externally? I recommend you take a look at the existing function used on load-source-file-function (i.e. load-with-code-conversion): it loads the source file into a buffer and then calls `eval-buffer`. So all it would take is for you to erase the text (aka non-code) part of the source code before passing it to `eval-buffer` (but of course, only do it when that source is using your new format). Or instead of `eval-buffer` you might "manually" skip the text parts, then use `read` + `eval` on the code parts. This would probably take a bit more effort in order to correctly handle (defvar foo). Stefan