[Top][All Lists]

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

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

From: arthur miller
Subject: Sv: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp
Date: Thu, 19 Dec 2019 00:02:02 +0000

I actually answered in my previous mail. You are wrong about

that this proposal would broke your tools.

Those 4 lines of C, would cost me many more lines of elisp, as least

as much as I can elisp (rather as little). I am currently fighting with

byte compiler which is mostly elisp and it does not go so well 😊. By

the way those 4 lines will be literally invisible (not entered) if one puts

a variable around them as I suggested.


For the record, even if I wrote an elisp package that implements this in

pure elisp, and somebody decides to write ”literal code” your existings

tools would still be broken. I don’t see how the implementation choice

would change that matter nor do I see why is it so big matter for you?


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


arthur miller <address@hidden> writes:

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

(Please do not double-space your messages.)

I have tried to explain this issue as clearly as I can.  I will ask once
more: Do you understand that Elisp code written in the way you propose
would not be compatible with existing tools which parse Elisp?  And that
such tools would require modification to parse such code correctly?

Stefan suggested ways to implement your idea as an alternative, literate
syntax, in a separate file format, by writing it in Elisp, using advice
and/or configuration variables, so that modification of the parser in C
would not be required, and the existing Elisp syntax and parser would
remain unchanged.  That is a great idea.  Why don't you want to do that?


reply via email to

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