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: Christmas wish: Literate Elisp Date: Sat, 21 Dec 2019 04:24:44 +0000 Message-ID: References: <87h81vhrek.fsf@russet.org.uk>, Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429731C7B58A7B6D367CA04962C0VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="199973"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Tim Cross , Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 05:25:04 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 1iiWK8-000psV-0x for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2019 05:25:04 +0100 Original-Received: from localhost ([::1]:36638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiWK6-0001d6-J9 for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2019 23:25:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40869) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiWJv-0001d0-5i for emacs-devel@gnu.org; Fri, 20 Dec 2019 23:24:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiWJr-0000KF-NR for emacs-devel@gnu.org; Fri, 20 Dec 2019 23:24:50 -0500 Original-Received: from mail-db8eur05olkn2032.outbound.protection.outlook.com ([40.92.89.32]:62497 helo=EUR05-DB8-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 1iiWJq-000083-PY for emacs-devel@gnu.org; Fri, 20 Dec 2019 23:24:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bi97DTQrPM5B3KcKkBBVR6q30o5lYBwlZvDPZA3Ltg+TBh7sl4JScvBp9/vOEnYubh7A6AQPS2/3s3ThV+LzFA1AVeHm0RXKPia5YRNmKCfgX1eLiyjIyA/yIGCvRh8cNvEJmnkrdsaaIW0h3GKlei7GAGAWKVEnDCD2NzePa98ICAOD7GKugvEKxdn2qYMkcOCqw4P1CMgbsDzOWBimJeWTTD4V0mMUgjX+pELfCyakLg0xr/TgU8qjKB1xNBx79SQ55DmCenFW4zgcg8PDUEvhzntyE1jLQoace3fPlxmcXW62oIrcj/ou+dX5VZy0ANMEqoMzETvu6C+Vxv/4Pw== 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=ToT5Z8kcXbwivQHY62JvUfRys+rtLhFpU/npriEA8YI=; b=TqXlxCQuNecAnujTPwbEmRIKstU7cQrlNVElc8/T7PJgzoNcVkKWX90BC7tQRmIcxfSh6dpHr06Cr/seBnHRspqM+IaCHoyRZB6vHObGCXlwQ7P3wYD/GEi9j6L8OHZ6fVPrvzAlAZPrL/+NYh1K843FQUfWBl5JsvKbgSpx79JAfYJMFSScEWbXIrn5ylsqopf22ZQ8qFl12oGsku4bNXNh+5+tN591AFupRRIIcSyC61DcmF+PgB2NupjSNoffQPLKcMZgGs/srYUmEKaYHwvomQ0VYbtSRM8HU7q6lMSq+Ul/pv/6eA+3NMYLDBlih2HHCb1gHCNEXfcgVeRRVg== 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=ToT5Z8kcXbwivQHY62JvUfRys+rtLhFpU/npriEA8YI=; b=GfyvO/eeaI9Tj8Ag1/hP58zmk4TqOcdIpaf6/rlie4u1hp5BPLMSF9YPTVIUqLAAp0m/E2d13BzYWig4k5uc6tVZfoBIi/a6kC57pbihWUr7pRpx/0ntdvqPm6l0aNAgxXhQA9/TL3bsVsEwr26Vpwcb37Yk8Glggkq6yY7hdSYGtKf0nWrZV+BZMy8Xfy24U8gZBlzWWxaEivUQOqQxdRjWVQ6XOYwISrbBic0IZInPN5Xn8vJVUch0ZirgNOWmKpOWLHsDLX8eWnS2JcBiv0aHpWcI8Vi54xwtSVth6hnQEjGM8XcLkYWsvIgIrXiHvk7jFJieqHTKMbU4GVm40w== Original-Received: from VI1EUR05FT054.eop-eur05.prod.protection.outlook.com (10.233.242.54) by VI1EUR05HT205.eop-eur05.prod.protection.outlook.com (10.233.242.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Sat, 21 Dec 2019 04:24:44 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.233.242.51) by VI1EUR05FT054.mail.protection.outlook.com (10.233.242.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Sat, 21 Dec 2019 04:24:44 +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; Sat, 21 Dec 2019 04:24:44 +0000 Thread-Topic: Christmas wish: Literate Elisp Thread-Index: AQHVsQLpbIcz5UxgfkCAm3tN+LzJEqe2wVZzgAyIENmAAI0FgIAALSae In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:4C3D052229DB940DFA90C3FC4B92AD8F6CBAA87DA1713BB0B0F92FD0D1AB6A0D; UpperCasedChecksum:347A5A76BF0EAB292BDC0E3906CEFAFFA076F5A0D632C2C938475E47F805A976; SizeAsReceived:7143; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [M5zwi77nw8lXzPw1Ek/wAwL1gPpat7MDWZHv5vkzGss=] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: b8ee0c1f-1011-4f3f-d304-08d785cdb4d9 x-ms-traffictypediagnostic: VI1EUR05HT205: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v/1CMQJgxM9ubiCkhYzwXCsblYDH1OLQBZy1dSaN4r1SdglstcYZA9oYFGWQ5Pul0sOn6xcXJcJ7b6CNOMknDIJNFI1K0/yM9VTygZR/E98M1tYY8eQqkGFklxVNaJB6Yue4W/NZ4FXnBI4sCQ4SpkzAZctsoJNb8ixMBKV1goxtCH7YvqJooa8PpyR0FllB 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: b8ee0c1f-1011-4f3f-d304-08d785cdb4d9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2019 04:24:44.4698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR05HT205 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.89.32 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:243530 Archived-At: --_000_VI1P194MB0429731C7B58A7B6D367CA04962C0VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Very interesting and nice read, thank you for taking your time Tim. I have no idea if literate programmign is very good or not.I certainly don't do it much. I never intended to present it as some kind of modern, silver bullet or something. I hope I didn't sound like that. I am aware that it is not the new idea either. Personally I really like ORG-mode and ipossibility to mix languages in one and same file. I was just looking at something I was working with and thought it had so much noise around stuff that matters. I wondered if it could be simplified. Then I got the idea that elisp could actually be written without special markers, since in elisp we put all code between () (with some exceptions). As I stated in my very first mail where I asked if we could have this in Emacs, I am not sure myself if this is somethign very usefull or just a cool gimmick. I personally can see some nice use cases, but it might not be of value to somebody else. I can maybe make a video where I play with it a bit after the hollidays it it is interesting. Yes, you are right about tools, checkers and so on. If we call it "literal = elisp" then one thing should be clear: literal elisp and elisp are not same. All elisp is literal elisp, but all literal elsip would not be elisp. Relevance= of this should be obvious to anyone, all current tools work with elisp, not literal elisp. So if you open a buffer and type comments without ';' in front, of course, identation, font locking etc will be confused. This shoul= d be self evident fact. Literal elisp would be a superset of elisp (with only one extra feature - different handling of comments). This is regardless of implementation language, just as elisp would be same language regardless if interpreter is written in C or Rust or Elisp for that matter. While yes, I have hacked C code, it does not mean I have altered how Elisp works. Elisp is still the very same, so even with the patch all Elisp should still work and parse the very same in Emacs and all external tools as it does since the beginning of the time. Look at the patch, apply it, run it. There is even boolean flag that eliminates that code at run tim= e if desired. I don't know how your lisp and your patches worked, not all Lisps are created equal. It is interesting experience you share, and I do understand what you mean and I agree with you. I am very conservative myself when it comes to making changes, what is not broken should not be repaired. I am also very pragmatic. I don't do changes just for changes sake, I do it only if it does something useful. Also, don't misstake me, I don't insist on change be done in C. I have done those changes the way I did because I am new to Emacs internals hacking. I am not new to programming, but I have no idea how they do in Emacs code, what API calls are there and so on. I also have limited with time. So I hav= e hacked where Emacs self help functionality and debugger has thrown me in. It turned to be some elisp and some C. I am sure it is possible to do this = in different ways, and if somebody is willing to implement some other way, please go ahead. Of those two ideas that Stefan outlined, I am not willing to implement them. First one is super brutish and inneficient, the second one is sane but involves too much work. I don't have knowledge and time to put into it. But I am sure it can be done. ________________________________ Fr=E5n: Tim Cross Skickat: den 21 december 2019 02:16 Till: Phillip Lord Kopia: arthur miller ; emacs-devel =C4mne: Re: Christmas wish: Literate Elisp I've been watching this thread and resisting adding to it, but feel now mig= ht be when I can contribute something useful. This whole discussion seems to centre around some views that literate progr= amming for lisp is a positive way forward and therefore, making changes to = both C and Elisp parsing is a good idea if it means we can move to a 'moder= n' literate programming model with greater ease. As someone who has done literate programming for non-trivial projects (i.e.= something other than my .emacs file), I think this assumption needs to be = challenged. Literate programming has been around for a long time, but has f= ailed to gain traction. Why? Is it due to the existing tools or is it somet= hing more fundamental? I have been a fan of Donald Knuth's work for a long time. When I first came= across literate programming in the mid-90s, I thought it sounded really in= teresting and a potentially great approach to writing code. A few of us ado= pted this approach in our project and embarked on this new path of discover= y. Unfortunately, the reality just did not hold up to the promise. Some of = this was due to limitations in tooling (relating to the 'weave' and 'tangle= ' tools of the time), but a big part really just failed because people don'= t move between prose and code that easily and we don't maintain the prose a= s well as the code. In the end, you just have lots of out-of-date prose mix= ed in with your code, which is often more misleading than no prose at all. The tools at the time were particularly poor when it came to working within= a REPL type environment. This was partly because they were a two step proc= ess (tangling) and you could only go in one direction (getting chagnes made= in the REPL back into your source was distracting and often forgotten, so = work was frequently lost). Dealing with scope, namespaces etc was a pain in= a system which relied on 'tangling' of source files in order to get the fi= nal output and nearly all supporting utilities (code formatters, highlighti= ng, linters etc) were broken. Like others who have posted in this thread, = we thought it could all be improved if you could eliminate the weaving/tang= ling and be free to just write prose within your code, so we tried to do th= is with the lisp we were using (sorry, can't remember what lisp flavor it w= as). At first glance, it looked very easy to do - a few tweaks to the parse= r, some new reader macros and we should be fine. On one level, it did fix s= ome of the issues, but we did find lots of unforeseen edge cases and it add= ed sufficient additional complexity to the whole system that in the end, we= decided it just didn't deliver the benefits we had hoped for. At the end = of the day, it wasn't the tools or the implementation which killed it - it = was simply that literate programming simply didn't fit with how people like= to code. It was one of those things which sounds nice in theory, but for m= ost, fails in practice. We did find the approach works better for some languages than others. For e= xample, languages like C, where you have a code, compile, run, test cycle, = it wasn't oo bad. However, for languages where you often included a more RE= PL driven style of devleopment, where lots of devleopment is done as experi= mentation/refinement at the repl, the paradigm added very little and more o= ften than not, just got in the way. We did find it was useful for smaller = tasks and configuration management, but for larger projects, especially wit= h teams of developers, it didn't stand up. So, my advice, for what it is worth is Implement a solution which does NOT require any modifications to either the= elisp parser or C code and use it to develop some non-trivial elisp packag= es. You could probably base it on org-mode. My suspicion is that you will f= ind that after some time, it really doesn't deliver what you hoped. However= , if I'm wrong, it will provide the necessary experience and familiarity to= help guide a more refined and targeted model for working with literate pro= gramming and elisp. Don't under estimate the effort or impact making changes to either the elis= p parser or C sources will have. There has been a number of comments in thi= s thread which makes it sound like you would just need to 'tweak' the parse= r and everything will work. That 'tweaking' is far more complicated than it= might seem on the surface. One of the main benefits of lisp dialects is th= ere simple syntax and the idea of code as data. Any changes made to either = the syntax or parsing of elisp is going to impact on lots of things, many o= f which none of us have even thought about yet. My feeling is that if literate programming is a great way forward, this wil= l be evident in the number of people who start using an elisp literate prog= ramming mode. If this does turn out to be the case, then we can use the exp= eriences from many people who are using that mode to see what can be done t= o develop the paradigm further. This may involve low level C or elsip parse= r or syntax changes, but they will be based on experience and demand. On Sat, 21 Dec 2019 at 03:56, Phillip Lord > wrote: Stefan Monnier > = writes: >> 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. > > The `sexpresso` Haskell package follows the same idea ;-) > > 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. I'm very late to this thread, for which apologies. My own package, lentic, could achieve this. It's gives you two visualisations of the same file; so one with comment characters, and one without. You can then do the literate part in one mode and the coding part in another. It already supports org-mode delination markers; it could be made to support brackets as a delineator too. Phil -- regards, Tim -- Tim Cross --_000_VI1P194MB0429731C7B58A7B6D367CA04962C0VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
Very interesting and nice read, thank you for taking your time Tim.

I have no idea if literate programmign is very good or not.I certainly = ;
don't do it much. I never intended to present it as some kind of modern,
silver bullet or something. I hope I didn't sound like that. I am aware
that it is not the new idea either.

Personally I really like ORG-mode and ipossibility to mix languages
in one and same file. I was just looking at something I was working
with and thought it had so much noise around stuff that matters. I 
wondered if it could be simplified. Then I got the idea that elisp could
actually be written without special markers, since in elisp we put
all code between () (with some exceptions). As I stated in my very first
mail where I asked if we could have this in Emacs, I am not sure myself
if this is somethign very usefull or just a cool gimmick. I personally can<= /div>
see some nice use cases, but it might not be of value to somebody else.
I can maybe make a video where I play with it a bit after the hollidays it<= /div>
it is interesting. 

Yes, you are right about tools, checkers and so on. If we call it "lit= eral elisp" 
then one thing should be clear: literal elisp and elisp are not same. All
elisp is literal elisp, but all literal elsip would not be elisp. Relevance= of 
this should be obvious to anyone, all current tools work with elisp, not&nb= sp;
literal elisp. So if you open a buffer and type comments without ';' in&nbs= p;
front, of course, identation, font locking etc will be confused. This shoul= d
be self evident fact. Literal elisp would be a superset of elisp (with only=
one extra feature - different handling of comments). This is regardless
of implementation language, just as elisp would be same language 
regardless if interpreter is written in C or Rust or Elisp for that= matter.

While yes, I have hacked C code, it does not mean I have altered how <= /div>
Elisp works. Elisp is still the very same, so even with the patch all Elisp=
should still work and parse the very same in Emacs and all external 
tools as it does since the beginning of the time. Look at the patch, apply<= /div>
it, run it. There is even boolean flag that eliminates that code at run tim= e
if desired. I don't know how your lisp and your patches worked, not all
Lisps are created equal. It is interesting ex= perience you share, and I do 
understand what you mean and I agree with you. I am very = conservative 
myself when it comes to making changes, what is not broken should not =
be repaired. I am also very pragmatic. I don't do changes just for = changes 
sake, I do it only if it does something useful. &nbs= p;

Also, don't misstake me, I don't insist on change be done in C. I have done=
those changes the way I did because I am new to Emacs internals hacking.
I am not new to programming, but I have no idea how they do in Emacs code,<= /div>
what API calls are there and so on. I also have limited with time. So I hav= e
hacked where Emacs self help functionality and debugger has thrown me in.

It turned to be some elisp and some C. I am sure it is possible to do this = in 
different ways, and if somebody is willing to implement some other = way,
please go ahead. Of those two ideas that Stefan outlined, I am not willi= ng
to implement them. First one is super brutish and inneficient, the secon= d 
one is sane but involves too much work. I don't have know= ledge and time
to put into it. But I am sure it can be done.

Fr=E5n: Tim Cross <theop= hilusx@gmail.com>
Skickat: den 21 december 2019 02:16
Till: Phillip Lord <phillip.lord@russet.org.uk>
Kopia: arthur miller <arthur.miller@live.com>; emacs-devel <= ;emacs-devel@gnu.org>
=C4mne: Re: Christmas wish: Literate Elisp
 
I've been watching this thread and resisting adding to it, but feel no= w might be when I can contribute something useful.

This whole discussion seems to centre around some views that literate = programming for lisp is a positive way forward and therefore, making change= s to both C and Elisp parsing is a good idea if it means we can move to a '= modern' literate programming model with greater ease.

As someone who has done literate programming for non-trivial projects = (i.e. something other than my .emacs file), I think this assumption needs t= o be challenged. Literate programming has been around for a long time, but = has failed to gain traction. Why? Is it due to the existing tools or is it something more fundamental?

I have been a fan of Donald Knuth's work for a long time. When I first= came across literate programming in the mid-90s, I thought it sounded real= ly interesting and a potentially great approach to writing code. A few of u= s adopted this approach in our project and embarked on this new path of discovery. Unfortunately, the reality jus= t did not hold up to the promise. Some of this was due to limitations in to= oling (relating to the 'weave' and 'tangle' tools of the time), but a big p= art really just failed because people don't move between prose and code that easily and we don't maintain the pr= ose as well as the code. In the end, you just have lots of out-of-date pros= e mixed in with your code, which is often more misleading than no prose at = all.

The tools at the time were particularly poor when it came to working w= ithin a REPL type environment. This was partly because they were a two step= process (tangling) and you could only go in one direction (getting chagnes= made in the REPL back into your source was distracting and often forgotten, so work was frequently lost). = Dealing with scope, namespaces etc was a pain in a system which relied on '= tangling' of source files in order to get the final output and nearly all s= upporting utilities (code formatters, highlighting, linters etc) were broken.  Like others who have posted = in this thread, we thought it could all be improved if you could eliminate = the weaving/tangling and be free to just write prose within your code, so w= e tried to do this with the lisp we were using (sorry, can't remember what lisp flavor it was). At first glance, it= looked very easy to do - a few tweaks to the parser, some new reader macro= s and we should be fine. On one level, it did fix some of the issues, but w= e did find lots of unforeseen edge cases and it added sufficient additional complexity to the whole system th= at in the end, we decided it just didn't deliver the benefits we had hoped = for.  At the end of the day, it wasn't the tools or the implementation= which killed it - it was simply that literate programming simply didn't fit with how people like to code. It wa= s one of those things which sounds nice in theory, but for most, fails in p= ractice.

We did find the approach works better for some languages than others. = For example, languages like C, where you have a code, compile, run, test cy= cle, it wasn't oo bad. However, for languages where you often included a mo= re REPL driven style of devleopment, where lots of devleopment is done as experimentation/refinement at the rep= l, the paradigm added very little and more often than not, just got in the = way.  We did find it was useful for smaller tasks and configuration ma= nagement, but for larger projects, especially with teams of developers, it didn't stand up.

So, my advice, for what it is worth is

Implement a solution which does NOT require any modifications to eithe= r the elisp parser or C code and use it to develop some non-trivial elisp p= ackages. You could probably base it on org-mode. My suspicion is that you w= ill find that after some time, it really doesn't deliver what you hoped. However, if I'm wrong, it will prov= ide the necessary experience and familiarity to help guide a more refined a= nd targeted model for working with literate programming and elisp.

Don't under estimate the effort or impact making changes to either the= elisp parser or C sources will have. There has been a number of comments i= n this thread which makes it sound like you would just need to 'tweak' the = parser and everything will work. That 'tweaking' is far more complicated than it might seem on the surface.= One of the main benefits of lisp dialects is there simple syntax and the i= dea of code as data. Any changes made to either the syntax or parsing of el= isp is going to impact on lots of things, many of which none of us have even thought about yet.

My feeling is that if literate programming is a great way forward, thi= s will be evident in the number of people who start using an elisp literate= programming mode. If this does turn out to be the case, then we can use th= e experiences from many people who are using that mode to see what can be done to develop the paradigm furthe= r. This may involve low level C or elsip parser or syntax changes, but they= will be based on experience and demand.

On Sat, 21 Dec 2019 at 03:56, Phill= ip Lord <phillip.lord@russ= et.org.uk> wrote:


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> My proposal is to slightly change Elisp parser to treat lines that= start
>> with any other printable character but '(' as a start of comment a= nd to
>> simply ignore the line, just as it treats ';' as a comment.
>
> The `sexpresso` Haskell package follows the same idea ;-)
>
> As for using it in Elisp: I don't think there's anything stopping anyo= ne
> from making such a `literate-elisp-mode` and even arrange for `load` t= o
> 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.


I'm very late to this thread, for which apologies.

My own package, lentic, could achieve this. It's gives you two
visualisations of the same file; so one with comment characters, and one without. You can then do the literate part in one mode and the coding
part in another.

It already supports org-mode delination markers; it could be made to
support brackets as a delineator too.

Phil



--
regards,

Tim

--
Tim Cross

--_000_VI1P194MB0429731C7B58A7B6D367CA04962C0VI1P194MB0429EURP_--