From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id ad9c49db for ; Sat, 17 Aug 2019 05:32:11 +0000 (UTC) Received: (qmail 11877 invoked by alias); 17 Aug 2019 05:32:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44677 Received: (qmail 11149 invoked by uid 1010); 17 Aug 2019 05:32:03 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f48.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25538. spamassassin: 3.4.2. Clear:RC:0(209.85.167.48):SA:0(-1.9/5.0):. Processed in 3.976555 secs); 17 Aug 2019 05:32:03 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.167.48 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=iJrYR7Sgp87obw56u9cgnpIIAvSYycaToAOPBDWBHrk=; b=cEQUrRDNauY6JfLpTZPUo3zDIm7yFBftOra53m9J2PaW+gzw602D2ShAdH6yWuUHgf WL4b3+PlDGdKAyheJtVc6uK+lJQLoktNw80Rehts6tDWo+whv+fYvcIH38x3XGMXShu4 Fz3Vt87nMv5TVmcMpzBnGbxm7Vv8xafxDfWbgBWko05k0ELkMJJosx2y4ENFf3x5k4qq BfLLl6IDdpCoJjdNXzxBQ2MFqZDf/HBcLx+wiLFmXQOvvD41FuDfTviAwJVNKgnU/153 5eRog3bdysT81iC1u3dnPBmwR2VBatPg0oWqflAlzFOYxEKTblrBjnY0j3MMAK346qMi oxOg== 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:content-transfer-encoding; bh=iJrYR7Sgp87obw56u9cgnpIIAvSYycaToAOPBDWBHrk=; b=Q53KZOYkFH3EJPh4GAs6N0DZcYcXTKLy4DVWBMTORLpHSMnUT3W+Mk/h5RAPpsuQX1 KTR4Ofh6+w8oOlAiDFMtzJMFEfHWfQ8yue8zR0L/tShsNSVMVjsE5v8kkr2dwV/muhGH hM3se/G4lkEBdO0B1bIj+jy/6576VW08C7z+GvAK2vbaYoXPdVGG/bBJ41+c/JXfhrb4 LRJ44oPSJN0Scz/aE/itdSXIKaJsds76jLsWprU+UInW7eH9aE/tjndppL2RFzsyajID hP3sU+l4LGIgwnLm0pjfzMFvqUwAjgkQs+lPmC82M+69oBZVYrhn1f9KtsEimWhKXSyd XINA== X-Gm-Message-State: APjAAAVAv8n5tT5z2sk4ow2/3SuYqzbJu/3zM6f51piL7NTyEIgHgeb5 lgQ+vt5kAQTbS01CicSnT51+1EdEbbF9Yrvzw+oOu9LnilQ= X-Google-Smtp-Source: APXvYqxJ878inA4pGCKOt4FutL+qdiekOjtqaKYruIVyMxJSGlrs4LTPOKjY2zhAU6fgcqH/Le03JL0cmarA7NGJXkU= X-Received: by 2002:a19:7006:: with SMTP id h6mr6953737lfc.5.1566019883597; Fri, 16 Aug 2019 22:31:23 -0700 (PDT) MIME-Version: 1.0 References: <2c845fb0-d628-400f-a805-ad8356b6d87a@www.fastmail.com> <7EBD1ADA-7179-4EEF-97CA-DBE4371D80D6@icloud.com> <876f807b-dfdd-4246-8cfe-7cf6f373ac88@www.fastmail.com> In-Reply-To: From: Bart Schaefer Date: Fri, 16 Aug 2019 22:31:11 -0700 Message-ID: Subject: Re: [Feature Request] Adding option to support triple quotes To: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2019 at 6:13 PM Aryn Starr wrot= e: > > The only preventive measure I can think of is to tell users to check zsh= =E2=80=99s 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 delimi= ter } let foo=3D:"{{{ 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=3D@{ :"( string one ) :'< string two > :^[ string three ] } # no, I do not have any idea what :^ would mean ... let hash=3D%{ key=3D:"( value ) }