From: Stephane Chazelas <stephane@chazelas.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Block comments ala Ray
Date: Mon, 15 Feb 2021 17:43:56 +0000 [thread overview]
Message-ID: <20210215174356.7kcrfk247j5vrg3y@chazelas.org> (raw)
In-Reply-To: <CAH+w=7Yydsx6QMhmKj5V_TX6-0sLKo9nNm3t07fsnhd5SKGj8Q@mail.gmail.com>
2021-02-14 12:15:31 -0800, Bart Schaefer:
[...]
> > - those !#, #! look too much like a shebang.
>
> Which actually doesn't matter, because #! isn't special anywhere but
> the first line.
>
> > - !# is already histsubst syntax.
>
> Also doesn't matter, this was intended only to operate where history
> is disabled anyway.
>
> > - It's also the !# extendedglob
>
> You mean "zero or more occurrences of '!' "? This is another reason I
> was only allowing "!#" at the start of a line. Under what
> circumstances would you begin a new line with that glob?
>
> > - It's also (POSIXly) invoking the !# command.
>
> Yes, I mentioned that. It seems pretty damn unlikely to use that, as
> it has no effect other than to set $? to 1.
Those were more objections on style ground than to say it was
an incompatible change.
I can imagine someone seeing:
!#
some
code
#! end
And thinking "is that remnants of mistyped shebang?", "why 0 or
more !s?", "what's that history expansion doing in there...?".
[...]
> > - syntax is a bit obscure and uncommon.
>
> Intentionally so, yes. It has to be something that would essentially
> never appear in an existing script.
I rather meant "something that one would not readily associate
to a block comment", though I'll admit that none of the
alternatives I suggested are any better.
[...]
> > Does it have to be delimited with whitespace? Can we
> > use !########### .. ##############!? That ! is easy to miss.
>
> Those are among the reasons I didn't think forming "inline comments"
> was a good idea.
[...]
> > - assuming we allow nesting (which would be useful to comment
> > out sections of code that contain block comments),
>
> I hadn't considered nesting. You can't nest C /* ... */ comments, and
> this was not intended to work any differently.
But the only use I can imagine for those !#...#! block comments
are to comment out code. That's why you use #if 0 in C for that
(so you can comment out code that contains comments).
I wouldn't use those for commenting (for inline documentation),
just like in C, we use
/*
* multiline
* comment
*/
For long comments as comments formatted as:
/*
multiline
comment
*/
make the code less legible as it's less clear what is code and
what is comment.
I could use a C-like comment that allows me to do things like:
rsync -v --inplace \
--stats -xazAX --delete \
--numeric-ids !# don't want the dependency on NSS #! \
--hardlinks
Though at the moment, we can already do:
rsync_options=( -v --inplace
--stats -xazAX --delete
--numeric-ids # don't want the dependency on NSS
--hardlinks
)
rsync $rsync_options
[...]
> > Or ksh's <#((...)), <#.. <>; redirection operators.
>
> The possibility of wanting to add those would also argue against using
> "<#" or "<<#" as a comment introducer.
Yes, that's why I didn't suggest <#.
And also why I brought up those ksh93 operators, to suggests
there are more lexer changes that we may want to add to zsh in
the future.
Here, if it was my call, I would just not bother with a new
block-comment operator, at least not until one gave a good
reason why they would be useful and better than what we already
have.
--
Stephane
next prev parent reply other threads:[~2021-02-15 17:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 6:05 Bart Schaefer
2021-02-10 6:16 ` Roman Perepelitsa
2021-02-12 6:17 ` Bart Schaefer
2021-02-12 6:26 ` Bart Schaefer
2021-02-12 6:41 ` Roman Perepelitsa
2021-02-12 7:40 ` Stephane Chazelas
2021-02-12 7:46 ` Roman Perepelitsa
2021-02-12 15:30 ` Bart Schaefer
2021-02-12 15:45 ` Stephane Chazelas
2021-02-12 16:55 ` Bart Schaefer
2021-02-12 18:16 ` Lawrence Velázquez
2021-02-12 21:02 ` Stephane Chazelas
2021-02-12 21:12 ` Stephane Chazelas
2021-02-12 21:29 ` Bart Schaefer
2021-02-13 7:37 ` Stephane Chazelas
2021-02-15 22:28 ` Daniel Shahaf
2021-02-13 4:33 ` Bart Schaefer
2021-02-15 0:42 ` Greg Klanderman
2021-02-12 15:24 ` Matthew Martin
2021-02-12 16:18 ` Bart Schaefer
2021-02-15 21:30 ` Daniel Shahaf
2021-02-15 22:35 ` Bart Schaefer
2021-02-12 20:48 ` Bart Schaefer
2021-02-13 8:35 ` Stephane Chazelas
2021-02-13 8:53 ` Stephane Chazelas
2021-02-14 20:50 ` Bart Schaefer
2021-02-14 20:15 ` Bart Schaefer
2021-02-15 0:36 ` Vincent Lefevre
2021-02-15 1:07 ` Bart Schaefer
2021-02-15 1:38 ` Vincent Lefevre
2021-02-15 17:43 ` Stephane Chazelas [this message]
2021-02-15 22:06 ` Daniel Shahaf
2021-02-15 22:39 ` Bart Schaefer
2021-02-14 20:58 ` Bart Schaefer
2021-02-16 15:30 ` Juergen Christoffel
2021-02-16 17:21 ` Vincent Lefevre
2021-02-16 18:29 ` Bart Schaefer
2021-02-16 21:35 ` Juergen Christoffel
2021-02-16 18:21 ` pod documentation in zsh scripts (Was: Block comments ala Ray) Stephane Chazelas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210215174356.7kcrfk247j5vrg3y@chazelas.org \
--to=stephane@chazelas.org \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).