Sv: Sv: Sv: Christmas wish: Literate Elisp

[arthur miller]

> 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 <address@hidden> 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