From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17419 invoked by alias); 3 Oct 2016 16:50:11 -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: 39551 Received: (qmail 23354 invoked from network); 3 Oct 2016 16:50:11 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f174.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.174):SA:0(0.0/5.0):. Processed in 0.316926 secs); 03 Oct 2016 16:50:11 -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=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: sgniazdowski@gmail.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.220.174 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rlW2n+e8JRhoDzqRpKH4/qeJiPD40SKQRUf5DAzrVJc=; b=drgGfnwzy7TZp2RAy9O+YQhsSBm5Z5ijmbKwo35lCzcWO2J2iMHOOadLFQ/VkJYNdx RAW0/UWD8aFoIU+DJe1zAp60yQDByf4jGHVOppBMH3bHO0VlVUDfzmVo8eeosY6bnRsJ plB2npcgQM1CEe/jHR9bF6cSzHk5iDNfW2oEBG+/rGV0kC+g+b9hSnq1bjA0cGDEmb8X xR/+8NHv/FsQ/LwKUf8S9XBgaaXiasbB/Ts+ISmJt0SG5c1bMDC5R+ZKxzN5LuKA0tCF YTfdmlg1bx4Gaaw3FFhSEMKD8OQE2ujEQc/R2n6czOKTgE1ZAhWNxNurXGnkevZnX+x5 hUWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rlW2n+e8JRhoDzqRpKH4/qeJiPD40SKQRUf5DAzrVJc=; b=PBt5VbDC1pQVdxW6wSs1BZejNqxMjhFAHTauFTg4m44YqY8IeZXNZuiNzYSKTlBswF Tqo1O5nHAVL1CnEUzDVuusXFqRzgahRvdb3Pv1pmJAcOfmqF3dHo+bf0Cu/5x6KI6i94 M/Nwq3XELJXINCe23YPWkUmeqZsyA2mswvgjFkkx1Z2g3kBRa/FcijUjkgSLsg0tI3Eu JQHIdX9BjKsvIhIe2CZ72sn1rmHaV0wxH35SO8ZaBU26SGnC6gj2isqoqACcSnUeFJQf u9eGe6hIrVGI6xBfbLshD9ytbLrVGfZBPIoCdy9F5MmDdWS+hik3vCTQ9w0PGX/H9EE6 B+YQ== X-Gm-Message-State: AA6/9RmO4jVCsBW8tu+fTUPMvQGvJDC9w4XlQdD8GmqUWC3fO55RY3WG8/pUNzG4/Sm7ooU8vvg7njdqErEklA== X-Received: by 10.55.26.17 with SMTP id a17mr19358546qka.250.1475513031453; Mon, 03 Oct 2016 09:43:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <161003084947.ZM7346@torch.brasslantern.com> References: <161002162145.ZM22574@torch.brasslantern.com> <20161003111840.3e5081f0@pwslap01u.europe.root.pri> <161003084947.ZM7346@torch.brasslantern.com> From: Sebastian Gniazdowski Date: Mon, 3 Oct 2016 18:43:30 +0200 Message-ID: Subject: Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 October 2016 at 17:49, Bart Schaefer wrote= : > On Oct 3, 12:00pm, Sebastian Gniazdowski wrote: > } > } On 3 October 2016 at 01:21, Bart Schaefer w= rote: > I think that's probably best left up to the person implementing the > scheduled function. Also minimally complicated if the code below > zlecore() doesn't have too many special cases for recursive-edit. So being in .recursive-edit is detectable from scheduled function? How? > Indeed, try this: > > diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c > index 0b3b1fc..04b9357 100644 > --- a/Src/Zle/zle_main.c > +++ b/Src/Zle/zle_main.c > @@ -471,7 +471,7 @@ calc_timeout(struct ztmout *tmoutp, long do_keytmout) > > tfdat =3D (Timedfn)getdata(tfnode); > diff =3D tfdat->when - time(NULL); > - if (diff < 0) { > + if (diff <=3D 0) { > /* Already due; call it and rescan. */ > tfdat->func(); > continue; It works, I have following debug messages generated after lucky Ctrl-C issued when in .recursive-edit: raw_getbyte() - queueing_enabled (0) CALLING diff[0] queueing_enabled (0) N-O-T CALLING diff[1] queueing_enabled (0) -- INIT tmout.tp(2) ZTM_NONE(0) ZTM_KEY(1) / BEGIN RAW_GETBYTE() zle_main.c So, calc_timeout() returns tmout.tp =3D=3D 2, which is ZTM_FUNC, and does that because the diff[0] inside-calc_timeout call of scheduled function did apparently reschedule =E2=80=93 the "N-O-T CALLING" entry, generated in else{} of if(diff <=3D0). Best regards, Sebastian Gniazdowski