From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vladimir Nikishkin Newsgroups: gmane.emacs.bugs Subject: bug#44554: 27.1; Feature request: SRFI-62 style comments for Emacs Lisp. Date: Tue, 10 Nov 2020 23:11:45 +0800 Message-ID: References: <87sg9hwbo8.fsf@delllaptop.lockywolf.net> <87mtzpgsz7.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b2036805b3c2195a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37469"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44554@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 10 16:15:44 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcVN2-0009Wu-2J for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Nov 2020 16:15:44 +0100 Original-Received: from localhost ([::1]:58972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcVN0-00017D-VW for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Nov 2020 10:15:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcVKQ-00079Q-94 for bug-gnu-emacs@gnu.org; Tue, 10 Nov 2020 10:13:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55305) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kcVKP-0002zQ-T4 for bug-gnu-emacs@gnu.org; Tue, 10 Nov 2020 10:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kcVKP-0005TP-OM for bug-gnu-emacs@gnu.org; Tue, 10 Nov 2020 10:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Vladimir Nikishkin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Nov 2020 15:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44554 X-GNU-PR-Package: emacs Original-Received: via spool by 44554-submit@debbugs.gnu.org id=B44554.160502112820975 (code B ref 44554); Tue, 10 Nov 2020 15:13:01 +0000 Original-Received: (at 44554) by debbugs.gnu.org; 10 Nov 2020 15:12:08 +0000 Original-Received: from localhost ([127.0.0.1]:38618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kcVJX-0005SE-Sa for submit@debbugs.gnu.org; Tue, 10 Nov 2020 10:12:08 -0500 Original-Received: from mail-lf1-f54.google.com ([209.85.167.54]:45887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kcVJV-0005Ri-Kv for 44554@debbugs.gnu.org; Tue, 10 Nov 2020 10:12:06 -0500 Original-Received: by mail-lf1-f54.google.com with SMTP id z21so16713140lfe.12 for <44554@debbugs.gnu.org>; Tue, 10 Nov 2020 07:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tLug1EF3v6BCsQ1Jn5pkvf2q6ITRMogVy10sw6buKE0=; b=Gnc2Y9+JShWPj+xih1zmIBVWlLwdv4GkrBsbh4tNNBiIEko4GU1ER+Sq9WdtCYhmdB LPcbcNf/4/WcBeiPbWCTEyjoIVeqJH1r6Fx3f5yT5dBND53t/2jGCiwuPKHn2248QCZo XjVr8PCZGXC1vFfO3zkL9P1HKCFwtqqzytoOdIvk0AAOBTP2UEPpsI5BvNlmN2qgkgQJ IN+n8cNDtMaO3DCRwl8q8NP0Bml+6fmlAdU3EKexBMKiWKRvuq+KX9QFQo8weWNUHcUg 8Ekco63rQw/f0f2p8MKVidwemW4nimVcMlhmX3oa6dTNO7gjmjKv9/NJJGVFnPhXsT0u k+eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tLug1EF3v6BCsQ1Jn5pkvf2q6ITRMogVy10sw6buKE0=; b=pPvhzpz/SH2MeHMw6VZLQ2es8StJP0B+xRZg9ioehVO9V99c+VraKZd/iDo1o1Woy7 i3aUPlUJV8WCa/6Sy1OnVTNsPOAS2mZcG8Sr8ufnD47ggWRNMS5xF1Atim2Zf3LG4zdz dsQkkFYvLCfR+47OAkZ/z55V/g8xVBfqt13G+ZHbfNECEMk4KbzOKIlGPYE+TOuiNKWy OfCcxBmKJ77TEn0KRvdpeKbhTncs7xwacrvvp57XIlkmcGW79SsD3E3RfdrktIfUtOPV p/VN1BuNRurb6bfnvU50SmlFOpeIur5KJe8526aKtXZW0cW0CZEECmldYaEx4wJq2vLV Axrg== X-Gm-Message-State: AOAM531d6vs2sW9018X34dhF9O2q8Ivzbdl54N0PCem9qQatcfENJJXh lGyDvEInpOQ+ZVn06mTlzUwswz5fmxJtoeznu+Y= X-Google-Smtp-Source: ABdhPJwEeCyPsEAJo0CdUKUfYqqVGxCpfFv7u9NnStKddREyBFXHEphbDBXsNhdu90yz+NrsZoUczbNo72bTcKCmxHw= X-Received: by 2002:a19:bed7:: with SMTP id o206mr7044255lff.360.1605021119675; Tue, 10 Nov 2020 07:11:59 -0800 (PST) In-Reply-To: <87mtzpgsz7.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:193021 Archived-At: --000000000000b2036805b3c2195a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, fontification usually solves the problem of "slightly hard to read" for me, because it's usually very different in co colour. Speaking of block comments, I have no opinion about that. The point of s-comments is exactly that they keep sexp syntax intact. Block comments are not expected to do that (even for the human languages within the comments). -- Yours sincerely, Vladimir Nikishkin (Sent with Google mail mobile.) Lars Ingebrigtsen =E4=BA=8E 2020=E5=B9=B411=E6=9C=8810=E6= =97=A5=E5=91=A8=E4=BA=8C 22:57=E5=86=99=E9=81=93=EF=BC=9A > Vladimir Nikishkin writes: > > > #;(defvar demo-variable nil > > "This is a demo-variable declared to illustrate SRFI-62.") > > ``` > > > > The special reader syntax "#;" means "please, ignore the next valid > > s-expression completely". > > Sexp-based comments would certainly be nice, but I wonder whether > comment blocks would be even more useful (if we have to prioritise): > > #| this is > a comment |# > > The advantage is that you don't have to have syntactically valid things > in comment blocks, while #; requires that you do. #; also looks like > slightly hard to read if you do stuff like > > (foo #;(foobar > ... > 1) > zot) > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > --000000000000b2036805b3c2195a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, fontification usually solves the problem of &q= uot;slightly hard to read" for me, because it's usually very diffe= rent in co colour.

Speak= ing of block comments, I have no opinion about that. The point of s-comment= s is exactly that they keep sexp syntax intact.=C2=A0
Block comments are not expected to do that (even for the human languages = within the comments).

--
Yours sincerely, Vladimir Nikishkin
(Se= nt with Google mail mobile.)

Lars Ingebrigtsen <larsi@gnus.org> =E4=BA=8E 2020=E5=B9=B411=E6= =9C=8810=E6=97=A5=E5=91=A8=E4=BA=8C 22:57=E5=86=99=E9=81=93=EF=BC=9A
Vladimir Nikishkin <lockywolf@gmail.c= om> writes:

> #;(defvar demo-variable nil
>=C2=A0 =C2=A0"This is a demo-variable declared to illustrate SRFI-= 62.")
> ```
>
> The special reader syntax "#;" means "please, ignore th= e next valid
> s-expression completely".

Sexp-based comments would certainly be nice, but I wonder whether
comment blocks would be even more useful (if we have to prioritise):

#| this is
a comment |#

The advantage is that you don't have to have syntactically valid things=
in comment blocks, while #; requires that you do.=C2=A0 #; also looks like<= br> slightly hard to read if you do stuff like

(foo #;(foobar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1)
=C2=A0 =C2=A0 =C2=A0zot)

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no
--000000000000b2036805b3c2195a--