From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24380 invoked by alias); 21 Sep 2016 21:39:12 -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: X-Seq: 39409 Received: (qmail 22806 invoked from network); 21 Sep 2016 21:39:12 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f65.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.65):SA:0(0.0/5.0):. Processed in 0.162383 secs); 21 Sep 2016 21:39:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=IJcvVm17vn32vGJhRCapHp5bNFpzYBITu8XMDCOE180=; b=xT0thvFdhaK+SLszdIN8omKPADFqBqzOlKzjgClmWnnM528ptg78AUtj2KAZCrg8qg woAZAz5qnC1Ijk0mwdpqFgGpimhWx6nBr0xxhN33JALfDRwso+EWDhhiz3l2SyD3oB07 yNbBrwYU8MjfXoxljUdRbZ6tIUzU6zE0nAwF88zGOnhb3xJ/VN4utOTI7Rb/6h2BI2pm 2Rgy+DQSwNbHTHs707SY8dcKfILPDEEWFOTemxSUO5WzGa27VLujIytUM3WGsPrRDyjp sYQk0nYG8FdzxeSTGHbWK7vPOXSUmi1NkQh/Xeo90JxZQYfgydUz16YgTHtKgdc6jx4Z XMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=IJcvVm17vn32vGJhRCapHp5bNFpzYBITu8XMDCOE180=; b=PAjAOCs/R8d1ZKosWhBMY0BvuCSHCjBQPWOyYa2DAJ2yPvFN5wOboPpwKHSKn2XrOe YJJaoci2D8D46GWpiycgV/72veN7yUfv1VDDx0fpIFtXTm6no3NIi41GlQuiPspwrsBs qtQPF+E4WQ5b/Ed4DXMtVITSp67bPDBJQyr9p9yoSKcXYQJ+Z0/zneUqQ8WkoH2CMlPL mHDP1SwII5tXvwo7eymRm7k8NM95NPwdewzg3ENxTQnVVSmBgVeZpLkQWApeCQRq4EnX k7v8YESgQgKzOR0/lmkhEm2/h6To2s1Rfb21Uh6Avrsr3xAKZvoPWRRDpO/J8czSYbDJ 8q/A== X-Gm-Message-State: AE9vXwPaWF5WSzRF71k5ggCJNxP+yW34XngQZfAmfSUGfdou8mHZaufq270psw4ei+47cg== X-Received: by 10.67.23.41 with SMTP id hx9mr41757587pad.147.1474493057556; Wed, 21 Sep 2016 14:24:17 -0700 (PDT) From: Bart Schaefer Message-Id: <160921142420.ZM3676@torch.brasslantern.com> Date: Wed, 21 Sep 2016 14:24:20 -0700 In-Reply-To: <76611.1474487469@hydra.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: PATCH: print -v with an array" (Sep 21, 9:51pm) References: <53992.1474303843@hydra.kiddle.eu> <160919133047.ZM28795@torch.brasslantern.com> <76611.1474487469@hydra.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh workers Subject: Re: PATCH: print -v with an array MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 21, 9:51pm, Oliver Kiddle wrote: } Subject: Re: PATCH: print -v with an array } } Bart wrote: } > useful to have every reuse of the format add a separate entry to } > the buffer stack. Similarly for "print -s -f" and the history. } } I doubt that anyone would notice a change of behaviour. Is multiple } entries definitely more useful? I don't know of a specific use-case. It just seemed to make sense that if you deliberately designed the format to consume only part of the input on each pass, you might be expecting it to make separate entries for each chunk so consumed. Multiple buffer-stack entries might be less useful than multiple history entries just because the buffer stack is LIFO. } > (Currently -S is silently ignored if -f is given. Hmm. Not sure } > how that ought to work anyway.) } } -S is also missing from the completion function so I've missed that. } The only way it could work is for the parsing and splitting to be done } last. It doesn't even take more than one argument at the moment. Yes, I'm wondering if print -S -f ... should just be an error. } > It's probably a mistake/oversight with -c. The *embedded* newlines } > always get included. The question is whether } > } > print -l one two three four } > and } > print -l -v stuff one two three four } > print "$stuff" } > } > should produce identical output, rather than the latter having two } > consecutive newlines at the end. Whichever way we decide, the same } > really should also apply to -c. } } I'd vote for the two consecutive newlines in the case of both -l and -c. Feel free to fix this when you make whatever other tweaks emerge from the foregoing conversation.