It seems that there is a communications breakdown here. At the risk of
poking the bear, I'm going to try to see if I can help resolve it.

The place where you are adding 4 lines of C code does not change the syntax
of elisp as a whole; it merely changes the way that particular version of
emacs parses the new format. There is a large body of existing software
which will be totally unaware of your changes. That body is large enough
that it is doubtful that it can, as a practical matter, be reasonably
changed to not break on the syntax changes that you are proposing.

On the other hand, there are ways to accomplish what seems (at least to
some of us) to be your stated goals without requiring a change to the
syntax of elisp. Using that approach instead, that large body of existing
software would continue to work, and, over time, might eventually be
expanded to add extra value to the additions.

(This principle is often described as "be conservative in what you send,
and liberal in what you accept".)

I hope that helps.
~Chad

On Wed, Dec 18, 2019 at 4:03 PM arthur miller <arthur.miller@live.com>
wrote:

> 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 <adam@alphapapa.net>
> *Skickat: *den 19 december 2019 00:53
> *Till: *emacs-devel@gnu.org
> *Ämne: *Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp
>
>
>
> arthur miller <arthur.miller@live.com> 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?
>
>
>
>