emacs-devel
[Top][All Lists]
Advanced

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

Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp


From: arthur miller
Subject: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp
Date: Wed, 18 Dec 2019 23:18:59 +0000

Yes Adam you are correct, but altering parser does not necessary mean

that elisp will change in a way that will force you to change your

existing code or coding practice. I proposed it in a way that will simply

add an extra feature, which you don’t need to use if you don’t like it. It

is trivial to make it by default ”off” by introducing new variable one can

set in init file to enable it (or disable it, whichever is better for default).

Hope it makes it a bit more clear what I suggested.

 

Från: Adam Porter
Skickat: den 19 december 2019 00:00
Till: address@hidden
Ämne: Re: Sv: Sv: Sv: Christmas wish: Literate Elisp

 

Stefan Monnier <address@hidden> writes:

> Thre is no discussion of changing the existing syntax/semantic of
> Elisp here.  Arthur is proposing a new file format/syntax as an
> alternative to the use of weave/tangle or Org-mode.

That's not my understanding of what Arthur is proposing.  You did
propose an alternative file format in earlier messages when you wrote:

> As for using it in Elisp: I don't think there's anything stopping
> anyone from making such a `literate-elisp-mode` and even arrange for
> `load` to handle such a file (just like there is already a package
> that lets `load` work directly on .org files).  I'd welcome such a
> package in GNU ELPA.

And:

> Note that in my comment above I meant it in existing Emacsen,
> i.e. without any modification to the C code.  The idea is to make use
> of existing hooks such as `load-source-file-function` or
> `file-name-handler-alist`.  I'm not sure what hook could be used to do
> the same with byte-compilation, but in the worst case, an advice
> should do the trick.

But Arthur has been proposing to alter the Emacs Elisp parser itself,
e.g. when he wrote:

> My proposal is to slightly change Elisp parser to treat lines that
> start with any other printable character but '(' as a start of comment
> and to simply ignore the line, just as it treats ';' as a comment

And:

> I was able to make readevalloop do what I want. It was rather trivial
> to implement this (once I realized how it works 🙂). Emacs built fine
> and I was able to test wtih eval-buffer and eval-regionwhich worked as
> intended.

> It was just 4 code lines, I just copied codeto parse comment and
> change the condition in if-statement:

> However, byte compiler is not happy about this. It emits warnings for
> every word out of code blocks as references to free variables. I am
> not sure where to look to patch it, maybe another day.

And:

> If we would just use directives in comments then we already have org +
> babel. But I think 4 extra lines of C code to enable this feature in
> eval-loop was a trivial price to pay :-).

> Now I just wonder how to change the bytecode compiler. Unfortunately
> it seems to be much more involved process. I don't know if I can do
> it, since I am not so acquainted with Emacs internals, so it would be
> cool if someone more knowledgeable can at least hint me if not help.

I've looked again at all messages in the thread.  Am I missing
something?

 


reply via email to

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