From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25908 invoked by alias); 30 Sep 2016 22:00:49 -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: 39529 Received: (qmail 28260 invoked from network); 30 Sep 2016 22:00:49 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f48.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.48):SA:0(0.0/5.0):. Processed in 0.132391 secs); 30 Sep 2016 22:00:49 -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=L00QoEBKsnOuVqsNMqbJc3OUTO0xYpeUOopOkyEyXQk=; b=SR6jY3nuOiU8ZyCS3l5VkPyc3+j68frAU0TWlKax7GIMhtDsHB8D7YkQsQEpI81j3V Zdd7qfngzwB/MxzAEy+1/ucXISPuVg5XeXXANAK7YL2EjDP1sF+cDoKxq37Uhqv5uwwo YDNQNDfZHQ9DVWJGtyQdGTMcR1qS0n1Rj6roRNd0B59G4fin1RqTFlKTXByen3dQxb4F 4TqJ5GLQtPRwOEydh+dVslnUV8KY+CHGfpH7OgMEY7uFoSZqWC0dIl7Y600ICVoCmkHm GzoWW3/U/eeoBKc114yEns8xqbn266KT4TXHRdWOkHGhkKGxq2fegttZcNNzH66zX9qy lbCA== 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=L00QoEBKsnOuVqsNMqbJc3OUTO0xYpeUOopOkyEyXQk=; b=Jsws+ykh0TJI6Hkn9RjXgcRf3w6zILmGo4bqV5t5CiiIlqfUqzFG+shD3X117Rpc/Z SNQI6JVOdU8cg7C6PquI4bq+YvzTOKYylJ4Sc2nBEGy7phD43st1dIa27F2qlzVPqA00 JyZC8b4Z8G7rOR5UFnffm5H9ZlzsmZoCmDeuJXzcgIbX9RgBs/zEvupT2VPImr+SSPfr WTT0iTWS7JtWmuW51opMgGTCy5TA906uQtRFa8b1uT8LgzKP4VNTXdHI0Sd7WLBmYUQ4 TI94CIyUMQNvtgdjkJeV/ynjyCPL5BMA3csivAJbt3KpIXV158KndQQ4D0J8O+mB94s+ FtFw== X-Gm-Message-State: AA6/9RnPkZgCRl72YSwcOTAvsBSnu+dj5lPJPNwdNcv5BbxUNkm0Y5x/qDDxi2vWj7jXMA== X-Received: by 10.66.183.207 with SMTP id eo15mr15414089pac.128.1475272411252; Fri, 30 Sep 2016 14:53:31 -0700 (PDT) From: Bart Schaefer Message-Id: <160930145351.ZM17322@torch.brasslantern.com> Date: Fri, 30 Sep 2016 14:53:51 -0700 In-Reply-To: <20160930070347.GC23665@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: _dispatch (was Re: PATCH: [for consideration] TMPSUFFIX)" (Sep 30, 7:03am) References: <160925155112.ZM23899@torch.brasslantern.com> <20160926072546.GA28316@fujitsu.shahaf.local2> <160926091922.ZM26758@torch.brasslantern.com> <20160927070039.GA20798@fujitsu.shahaf.local2> <160927122050.ZM13394@torch.brasslantern.com> <20160928102417.GA2729@fujitsu.shahaf.local2> <160928114917.ZM32186@torch.brasslantern.com> <20160929063916.GA4351@fujitsu.shahaf.local2> <160929003047.ZM27818@torch.brasslantern.com> <20160930070347.GC23665@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: _dispatch (was Re: PATCH: [for consideration] TMPSUFFIX) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 30, 7:03am, Daniel Shahaf wrote: } Subject: Re: _dispatch (was Re: PATCH: [for consideration] TMPSUFFIX) } } Bart Schaefer wrote on Thu, Sep 29, 2016 at 00:30:47 -0700: } > The important bit would be that ERRFLAG_EVAL never converts directly } > back into ERRFLAG_ERROR, so if the script ignores TRY_BLOCK_ERROR } > then all errors disappear at the end of the always-block. } } This makes sense, but wouldn't it also require some way for the always } block to (manually) set ERRFLAG_ERROR again upon an ERRFLAG_EVAL, in } order to "abort enough code" (which was the original issue)? } } The interface could be [...] a setfn on TRY_BLOCK_ERROR That's what I was thinking of, yes. There's already a setfn that reacts to TRY_BLOCK_ERROR=0 so it wouldn't be hard to have one that notices when TRY_BLOCK_ERROR changes from 2 to 1 or some such. I'm not sure what kind of gyrations would be required for eval to be aware that it's inside a try-block, though.