From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 17:18:19 -0600 Message-ID: <87zhfpp6is.fsf@alphapapa.net> References: <87r213qkhm.fsf@alphapapa.net> <878sn9qxk3.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="81462"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 19 00:18: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 1ihiaY-000Kyi-W3 for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2019 00:18:43 +0100 Original-Received: from localhost ([::1]:33768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihiaX-0004lT-Gm for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 18:18:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51922) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihiaP-0004lL-1B for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:18:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihiaN-0000Hi-OB for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:18:32 -0500 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:60416 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ihiaN-0000Gu-Gt for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:18:31 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1ihiaK-000Kjx-JB for emacs-devel@gnu.org; Thu, 19 Dec 2019 00:18:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:243460 Archived-At: arthur miller writes: >> On the contrary, the semicolon prefix (and fontification according to >> my preferences in Elisp buffers) makes it easy for me to see what is >> code and what is prose. > > Aren’t starting ’(’ and ’)’ + identation enough? I explained in the message you quoted why they are not enough. Please read it carefully. >> No, in fact, some of my Elisp would have to change, because it would >> no onger be sufficient to look at comment prefixes to know whether a >> line s code or comment. Such a change would be very expensive in >> terms of the necessary human work that would ripple outward. And >> your proposed variable would not obviate the need to account for both >> states in my code. > > In which way? Can you alaborate more please? You would not need to > write anything special. If you don’t wish to write literal code, then > just don’t. Prefix your comment lines with ’;’ as currently and don’t > care about it, Everything will work as it does now. I don’t see a > problem there. If I am wrong please explain. You don't seem to understand. I am talking about existing code outside of emacs.git which parses Elisp, which would not be compatible with your proposed changes to Elisp syntax. >> This is the problem: as you have shown, parentheses commonly appear in >> prose, even at the beginning of lines. Punctuation, such as semicolons, >> do not >> ; or, at least, should not > > Yes, and it is always possible to construct some obscure case where > things break. Look for example at C or C++ and all undefined > behaviours in the standard. I mean, sure, there are always soem > obscurities, but do they matter? If one writes an article or a book or > some prosa and uses literal programming, and there is one explicit > case not allowed to use, how important is than to use exactly that > constrcut? I mean considering cons and pros, should one abandon the > entire idea because of one minor obscurity? Your own message showed how it happens in prose. In fact, it's common enough and ambiguous enough that Elisp already forbids open-parens at column 0 in strings and requires them to be escaped. How is this a minor obscurity? Don't you realize how important it is that syntax in a file format be unambiguous? > Well as I see literal programming it is to make it easier for humans > to mix code and prosa. What I proposedis just one small step further > in that direction. It is also a step toward ambiguity, churn, and bugs in other people's code, which you would not have to fix. > I don’t see how org makes it any different? In org you still have to > use both ’;’ and #+BEGIN_SRC - #+END_SRC markers. Have you used Org mode? Have you looked at a literate program written in an Org file? The point is that top-level comments are written between code blocks, without comment prefixes. > So it is even more clutter to eye. As I said in the message you're replying to: You can even choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually (or literally!) disappear. > It is about being able to simple write and mix code and text. If it is > good or bad idea is up to individual preference. I personally find it > a cool thing, you seem to think it violates old ways, I have said nothing about old ways. I explained exactly what the problems with the proposal are. Please read my message carefully. > As a small reflection about us humans being slentrians, I have an > illustration. Caves are still as good for living as they were 20 000 > years ago. We can for sure make many cases against living in houses > such as not being natural, can crash on it’s inhabitants, cost > resources to construct etc etc. But yet, pros of liiving in houses > outweigh far the cons, and not many people today prefer to live in a > cave. Sorry maybe ti is a too contrived illustration. Anyway, if you > are good with ’;’ just continue to use it. But if a change like this > does not seem to cost lots in development terms, then why opposing if > somebody else find it cool. It is just that is more elegant and in a > sense cool thing to be able to do it without special tools as some > markers. It's not cool to imply that citing technical problems with your proposal is like being a cave-dweller.