From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: Sv: Christmas wish: Literate Elisp Date: Fri, 20 Dec 2019 15:50:29 +0000 Message-ID: References: <87r213qkhm.fsf@alphapapa.net> <878sn9qxk3.fsf@alphapapa.net> <874kxxqlxz.fsf@alphapapa.net> <87v9qdp4x8.fsf@alphapapa.net> <207B2E96-FE0D-4F53-8D5F-1B6C96480661@traduction-libre.org> , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429710752459DBA3082F614962D0VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103110"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 20 16:50:46 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iiKY9-000QfF-EZ for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2019 16:50:45 +0100 Original-Received: from localhost ([::1]:58198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiKY8-00023W-4a for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2019 10:50:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53863) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiKXz-0001t2-4A for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:50:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiKXw-000821-Kn for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:50:34 -0500 Original-Received: from mail-oln040092074045.outbound.protection.outlook.com ([40.92.74.45]:30853 helo=EUR04-DB3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iiKXv-0007yp-Sy for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:50:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oVLMjFZprJcHY341kdbbqdYVDllwJvAiBz4y7e/lNg4/uKZbF80NkZj4I1KtQ49pg/Vrqnc4rH+siYpcL/K06v079yTdOnBp8GB5AvI/2QVLFObqhidOEFXano2LtdEM9LSLNZLKI/Cn41DX6t7z8GSqrCrvJahmH84KcTTADWNNEwSIbwzPpCFJHUWJNafHGBe5kxjO5ub4zubY0EQZ4tyrifRQGIkz/RY52MCKScyVfpqvU6l1GoSiXXFNmiP3nBck2P5AxUIIFi1uhMKOIenptiiSMyuZdZ9LzCyeAg1vcZ8Nwmp3HTx3B1qQUo368De8hcPEUHBTnUiceHhEtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7WhJIsW14jtFNCb/7cc450ndv2rXGrsMpG3RNtgyFeU=; b=nb2CAq7zyAY+reHpJlL9SbIXLpwhIH9SrPrYPBtui/mp/x8AIRy14eUSEE+fmynjeb7cDP5kUK5Pe4uZC4rTtJ4EEeV5FvAf71HIA+0B+qK0ezD2bPeROk6G4RG9A8A/zjGsBF/cFfQQMbC1B0zxa/wRDq8hzBZ5wB519+Bzv+ZMnKdFlr9gthw9BfVnjD7S52wbetgMMhvQMGeNR3LTLn9gK5xYURR3seDNABxJcds4nbd89vEHeCU20Sd6mW+xSuJwCpH+gzVZp1JnJbrp1an//KuWrHunelEeAy9qbJFLP9mOcVHqajfmqnYy5Sz6Nr9o/75eRLy7qFVB3d2KsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7WhJIsW14jtFNCb/7cc450ndv2rXGrsMpG3RNtgyFeU=; b=QakYlhYNjNILrlypyDJaQNVVi1Ibivr9SuvHGhxXAo/MrLxIUKVvYzt+fayRwMi440YdStgJFVXDmxzw46yOoEPmKLBpjBJgxjV1da5kcr9lyowQzMAvtDVeFwEDcERE41NKzjy7nJRv/IT3SyHbZRh6HeokLzF0jnrM9ZzcUj2MvGhDmuuKmdUsOug8M2NUJnuJIGXE/tvA/Z0UfLfN8Y7czL3g1FiqJc7CU9zUfR+t4AtBfa4hkvr4zPAAX4gu5SCY/kjpPgv+qtInOOKn5sMKLW/SoOjrtE3y8GFRl136hvtdF/7rk7nOYj6cVebXFopArMQSrZBLLC6kjz/rNQ== Original-Received: from VI1EUR04FT044.eop-eur04.prod.protection.outlook.com (10.152.28.51) by VI1EUR04HT162.eop-eur04.prod.protection.outlook.com (10.152.28.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Fri, 20 Dec 2019 15:50:29 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.152.28.51) by VI1EUR04FT044.mail.protection.outlook.com (10.152.28.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Fri, 20 Dec 2019 15:50:29 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46]) by VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46%5]) with mapi id 15.20.2559.016; Fri, 20 Dec 2019 15:50:29 +0000 Thread-Topic: Sv: Christmas wish: Literate Elisp Thread-Index: AQHVtg7XZh3uePLzWUOpz6g6ivEWNafCMoBmgADt+lGAAAh0WQ== In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:0CEA7CC1C64D2CE56403262C4A5D19974926D1E9A8D2E5AE1C857CDBEF47D445; UpperCasedChecksum:B276FA7120EF593FEC0D82CC0592332A8074036A4BC396093A0D79D34BAAB9D2; SizeAsReceived:8121; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [iUxhMoNXlca2d+AKGBWFOcsLJDhG5qnI] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: ef1b9ab5-0bf2-47fd-1d99-08d7856456ad x-ms-traffictypediagnostic: VI1EUR04HT162: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +M0ltN0KXuFfU47UFZTof8kk20jwZewLGBnFBxQpYXImPwX4kE5cVSejvLhhyKqbXbL8MJv07LyHen+R7a3qXJgSC8FnjlHAiwbgKtnCDT7YYSqF9d6503wkWt4AbwRH4cDiau+68LY2E62LtZt+sqGFdetlwhfRjzobMphSWFtXjuP0n5yQuJoOQxYkJfUC2QG6VWTkdnkDfWW2E1xcVgw58c+jOzXwQkLZ9ZXFTfE= x-ms-exchange-transport-forked: True X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: ef1b9ab5-0bf2-47fd-1d99-08d7856456ad X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 15:50:29.2934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR04HT162 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.74.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243512 Archived-At: --_000_VI1P194MB0429710752459DBA3082F614962D0VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable 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? The read-eval loop is not exposed to elisp, so one would need to implement own? Or am I missunderstanding? As I understand the elisps read-eval loop is part of C runtime core, so if one would implement another parser on top = of it, it would mean some kind of preprocessor to preprocess elisp before it i= s handled into elisp parser. Thisis only for read-eval loop. I believe it would mean lots of work, and maybe less efficiency since it mi= ght impose some extra copying/reading? I don't know, as I noted before I am not that very wellacquinted with Emacs internals so I can't tell for sure. Pers= onally I don't care in which way it is implemented as long as the result is the sa= me. Just as a note about the C change and hooks and runtime support: the flag I used lets me completely bypass the change to the "old" parser. Skipping comment lines is hard coded into read-eval loop, so I have just hacked arou= nd it, but if one would introduce some kind of modifiable read-eval loop with = hooks or I don't know what then it would probably need more C changes than waht I did. Byte compiler would also need some change since comments are hardcoded there as well. Also if one not introduce any change in byte compi= ler and read eval loop, it might mean one would preprocess elisp source in some hook, which might need extra loop through source file which is less effecie= nt. At least that is how I am reading the code, but I just started to hack it, = so I might be missing something. If one added a buffer-local flag instead of as I did = a global flag, then this could be that support in runtime to make it possible/easier= to support this. I don't know, I might be wrong, just as I see the code as of = the moment. ________________________________ Fr=E5n: Stefan Monnier Skickat: den 20 december 2019 16:00 Till: arthur miller Kopia: emacs-devel@gnu.org =C4mne: Re: Sv: Christmas wish: Literate Elisp Of course, this decision is not up to me, but I'll point out that I think I don't think we should change the C code to or the byte-compiler to directly support this new format. I'd welcome changes that add hooks to make it possible/easier to support such a format (and other formats like Org-mode), OTOH. Stefan arthur miller [2019-12-20 00:55:29] wrote: > Here is a little prototype to test my idea with literal Elisp. > > I have patched read-eval loop as stated in previous mail, in lread.c. > It is probably possible to implement that in Elisp, but I don't have > enough knowledge of either Emacs internals nor Elisp to do this in some > short time. It would took me a lot of time to look up all the > things I would need. Anyway, C code turned to be rather trivial, and also > completely by-passable if so desired, so I have introduced a user-customi= zable > variable 'emacs-lisp-allow-literal-comments', which is by default nil. > > I wasn't sure in which elisp file to introduce this variable, so I have u= sed > 'simple.el' found in lisp directory of Emacs source distribution. That fi= le > seems to have some other user customizable variables that affect elisp so= I > thought it might be appropriate place. > > For the byte compiler I have patched bytecomp.el, in rather brutish way, = but it > seems to work. It wasn't very difficult either, but I think I have done i= t rather > ugly. Someone might wish to refactor that code. Anyway, it is less then > twenty lines of code, and it is by default bypassed as well. The variable > that controls it is also user customizable and found in same file, > named 'byte-comp-allow-literal-comments'. > > I have attached also a small trivial elisp file for illustration purpose. > > It is just a test of an idea, and small prototype to show that it might w= ork. > It needs more thorough testing and can probably be implemented in some be= tter > way. > > I have tested on GNU/Linux and Windows. Emacs was able to compile it's ow= n > elisp as well as external packages I use. > > As a note, the change in C is completely backwards compatible. No logical > change to elisp parser happens when 'emacs-lisp-allow-literal-comments' > variable is nil. > > ________________________________ > Fr=E5n: Emacs-devel f=F6r > Jean-Christophe Helary > Skickat: den 19 december 2019 02:50 > Till: emacs-devel@gnu.org > =C4mne: Re: Christmas wish: Literate Elisp > > > >> On Dec 19, 2019, at 9:42, chad wrote: >> >> There is a large body of existing software which will be totally unaware= of your changes. > > Although I think the premise of your comment is absolutely valid, I'm not= so > sure about the "*large* body of existing software". > > > Jean-Christophe Helary > ----------------------------------------------- > http://mac4translators.blogspot.com @brandelune --_000_VI1P194MB0429710752459DBA3082F614962D0VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
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?

The read-eval loop is not exposed to elisp, so one would need to implement =
own? Or am I missunderstanding? As I understand the elisps read-eval loop
is part of C runtime core, so if one would implement another parser on top = of
it, it would mean some kind of preprocessor to preprocess elisp before it i= s
handled into elisp parser. Thisis only for read-eval loop.

I believe it would mean lots of work, and maybe less efficiency since it mi= ght
impose some extra copying/reading? I don't know, as I noted before I am not=
that very wellacquinted with Emacs internals so I can't tell for sure. Pers= onally
I don't care in which way it is implemented as long as the result is the sa= me.

Just as a note about the C change and hooks and runtime support: the flag I=
used lets me completely bypass the change to the "old" parser. Sk= ipping
comment lines is hard coded into read-eval loop, so I have just hacked arou= nd
it, but if one would introduce some kind of modifiable read-eval loop with = hooks
or I don't know what then it would probably need more C changes than waht <= br>
I did. Byte compiler would also need some change since comments are
hardcoded there as well. Also if one not introduce any change in byte compi= ler
and read eval loop, it might mean one would preprocess elisp source in some=
hook, which might need extra loop through source file which is less effecie= nt.

At least that is how I am reading the code, but I just started to hack it, = so I might
be missing something. If one added a buffer-local flag instead of as I did = a global
flag, then this could be that support in runtime to make it possible/easier= to
support this. I don't know, I might be wrong, just as I see the code as of = the
moment.
Fr=E5n: Stefan Monnier <= monnier@iro.umontreal.ca>
Skickat: den 20 december 2019 16:00
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
=C4mne: Re: Sv: Christmas wish: Literate Elisp
 
Of course, this decision is not up to me, but I'll= point out that
I think I don't think we should change the C code to or the
byte-compiler to directly support this new format.

I'd welcome changes that add hooks to make it possible/easier to support such a format (and other formats like Org-mode), OTOH.


        Stefan


arthur miller [2019-12-20 00:55:29] wrote:

> Here is a little prototype to test my idea with literal Elisp.
>
> I have patched read-eval loop as stated in previous mail, in lread.c.<= br> > It is probably possible to implement that in Elisp, but I don't have > enough knowledge of either Emacs internals nor Elisp to do this in som= e
> short time. It would took me a lot of time to look up all the
> things I would need. Anyway, C code turned to be rather trivial, and a= lso
> completely by-passable if so desired, so I have introduced a user-cust= omizable
> variable 'emacs-lisp-allow-literal-comments', which is by default nil.=
>
> I wasn't sure in which elisp file to introduce this variable, so I hav= e used
> 'simple.el' found in lisp directory of Emacs source distribution. That= file
> seems to have some other user customizable variables that affect elisp= so I
> thought it might be appropriate place.
>
> For the byte compiler I have patched bytecomp.el, in rather brutish wa= y, but it
> seems to work. It wasn't very difficult either, but I think I have don= e it rather
> ugly. Someone might wish to refactor that code. Anyway, it is less the= n
> twenty lines of code, and it is by default bypassed as well. The varia= ble
> that controls it is also user customizable and found  in same fil= e,
> named 'byte-comp-allow-literal-comments'.
>
> I have attached also a small trivial elisp file for illustration purpo= se.
>
> It is just a test of an idea, and small prototype to show that it migh= t work.
> It needs more thorough testing and can probably be implemented in some= better
> way.
>
> I have tested on GNU/Linux and Windows. Emacs was able to compile it's= own
> elisp as well as external packages I use.
>
> As a note, the change in C is completely backwards compatible. No logi= cal
> change to elisp parser happens when 'emacs-lisp-allow-literal-comments= '
> variable is nil.
>
> ________________________________
> Fr=E5n: Emacs-devel <emacs-devel-bounces+arthur.miller=3Dlive.c= om@gnu.org> f=F6r
> Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org= >
> Skickat: den 19 december 2019 02:50
> Till: emacs-devel@gnu.org <emacs-devel@gnu.org>
> =C4mne: Re: Christmas wish: Literate Elisp
>
>
>
>> On Dec 19, 2019, at 9:42, chad <yandros@gmail.com> wrote: >>
>> There is a large body of existing software which will be totally u= naware of your changes.
>
> Although I think the premise of your comment is absolutely valid, I'm = not so
> sure about the "*large* body of existing software".
>
>
> Jean-Christophe Helary
> -----------------------------------------------
> http://mac4translators= .blogspot.com @brandelune

--_000_VI1P194MB0429710752459DBA3082F614962D0VI1P194MB0429EURP_--