zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [Feature Request] Adding option to support triple quotes
Date: Fri, 16 Aug 2019 22:31:11 -0700	[thread overview]
Message-ID: <CAH+w=7bh3d950w_kT8KN5MeDjagapuoSqbWRBmFo8S=ZTUnwvg@mail.gmail.com> (raw)
In-Reply-To: <AAFFC725-E38F-4307-8E21-8A443FC0FFBC@icloud.com>

On Thu, Aug 15, 2019 at 6:13 PM Aryn Starr <whereislelouch@icloud.com> wrote:
>
> The only preventive measure I can think of is to tell users to check zsh’s version at the very start and exit noisily ...

This right here is exactly why we have traditionally never built new
syntax that is an ambiguous superset of an existing syntax.  If it's
not a syntax error in a version of the interpreter that doesn't
support it, it shouldn't be there at all.  I've been staying out of
this discussion because it's all been theoretical so far, but tripling
quotation marks is a nonstarter for me.

A good relatively recent example of this is that you're allowed to write

{ stuff } always
{ other stuff }

but not

{ stuff }
always { other stuff }

So if you really want to make progress with this, start looking for
something more akin to perl's q{} and qq{} as already mentioned.  The
difficult part is that the shell language uses "lexical pasting"
instead of a concatenation operator, so finding something that doesn't
already have another meaning is tricky.

One way around this is to introduce a new keyword.  A candidate that
occurs to me is "let", because it's already a builtin and it's been
decades since I saw anybody use it.  (Does anyone know of a program
named "let" with which this would collide, and that isn't already
basically unusable in zsh because of the builtin?)  The "let" builtin
expects math expressions, which already have a limited syntax, so it's
easier to find something that would break in an old shell.  For
example, a math expression can't begin with a colon, so that could
introduce a new quoting token.

This also means you can turn the syntax off with "disable" if you
don't want it, we don't have to create another setopt.

Qualification:  I'm not sure the following suggestions would actually
error soon enough to prevent some downstream syntax from being
interpreted/executed, so this probably still needs more thought.

Nevertheless you could have (just throwing out examples)

let :"( this is like a triple double quoted argument to the ":" builtin )
let :'{ similarly a triple single quote , and look we can choose our delimiter }
let foo=:"{{{ assign to foo, and quote } and { by having the delimiter
repeat }}}

There are other characters that can't begin a math expression that
could be given other meanings, such as ^ and @ and %

let list=@{ :"( string one ) :'< string two > :^[ string three ] }   #
no, I do not have any idea what :^ would mean ...
let hash=%{ key=:"( value ) }

  reply	other threads:[~2019-08-17  5:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2c845fb0-d628-400f-a805-ad8356b6d87a@www.fastmail.com>
     [not found] ` <7EBD1ADA-7179-4EEF-97CA-DBE4371D80D6@icloud.com>
     [not found]   ` <876f807b-dfdd-4246-8cfe-7cf6f373ac88@www.fastmail.com>
     [not found]     ` <f053e72e-e22e-4729-a2de-eaa712119728@www.fastmail.com>
2019-08-15 16:23       ` Aryn Starr
2019-08-17  5:31         ` Bart Schaefer [this message]
2019-08-17  6:30           ` Stephane Chazelas
2019-08-17  8:19             ` Stephane Chazelas
2019-08-18  4:24             ` Mikael Magnusson
2019-08-18 18:58               ` Matching delimiters for the "e" glob qualifier (Was: [Feature Request] Adding option to support triple quotes) Stephane Chazelas
2019-08-18 19:55                 ` Bart Schaefer
2019-08-19  6:46                   ` Matching delimiters for the "e" glob qualifier Stephane Chazelas
2019-08-13  6:06 [Feature Request] Adding option to support triple quotes Aryn Starr
2019-08-13  9:06 ` Mikael Magnusson
2019-08-13 20:52   ` Aryn Starr
2019-08-13 16:28 ` Daniel Shahaf
2019-08-13 20:40   ` Aryn Starr
2019-08-14  9:54 ` Stephane Chazelas
2019-08-15 14:28   ` Aryn Starr
2019-08-15 15:56     ` Daniel Shahaf

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='CAH+w=7bh3d950w_kT8KN5MeDjagapuoSqbWRBmFo8S=ZTUnwvg@mail.gmail.com' \
    --to=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).