[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Sv: Sv: Sv: Christmas wish: Literate Elisp

From: arthur miller
Subject: Sv: Sv: Sv: Christmas wish: Literate Elisp
Date: Sat, 21 Dec 2019 01:18:50 +0000

> 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
GNU General Public License for more details.

    Eduardo Ochs

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]