From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21771 invoked by alias); 6 Dec 2016 21:21:36 -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: 40108 Received: (qmail 25651 invoked from network); 6 Dec 2016 21:21:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f172.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.217.172):SA:0(0.0/5.0):. Processed in 1.90093 secs); 06 Dec 2016 21:21:35 -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=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS,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: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.217.172 as permitted sender) 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=c8TD0EXj51et5dAD2bgp5nV4EwoKbyu+1V9/Atd9n7s=; b=RcJy/rXbiCQcU90RepHEi7dgUMmMTNMr9p0k9lnilwg1reuesBMlDdGT44M3pBetTv jsiRtqQoV9xWqXJfkK3oJvMLJ5Igzns/ARmFp5H5FqA7HSXceH5de/Srh8R1Uibf40Gh XP197UIvJRXE3gU4kHVxp9htzBKQJ4vD2Uff0h20hgLQkWchO5kcLOEKKvMZosLLe+vz 76//64muwwDudSUqQR+wRLcd9PMBggIzEgBjuoH2UOJ95/+w8Da1+moiSMBUMLitG8tr Tny367qbZGigeUWRJkMz0BocpMs/wYx7lfwpdWMFhFOH1eN4ALT2msPvGmvXLf3bkPpC Nccg== 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=c8TD0EXj51et5dAD2bgp5nV4EwoKbyu+1V9/Atd9n7s=; b=Q6YTtBP80sHx26QSnEMqtSfH8dJbUzKlfD7K5UJUl6QfNi5LfHNBdAV1PE8YHHz6mi fKIEIwSE3Mp6IPyvlBNsfgVaLCWiM7+6UO1I4gFN3VzIOqgpPGGoemBXlHjlcXZs0L0K V1tsUcc+5WFpwJQn1mzXnHkWB0NfCE8UoDbKk/G6cHuuFmyfvpaLeVJycIJqp0it1jW3 Ffp1QVNzWXUNSt4DPK49cGDsU8WjHsfwMXQ+DO+CFeYk5ejkQ39l6VuPF4wogU8Gcp/R hiHWz1xTenNEsInN5H4PPzT/qBP5BOL6vmqEuJGPa7BJH0fRt4jjHWlzbQl0uccQYewQ YPyA== X-Gm-Message-State: AKaTC03yZw1t6AhYr5oHsKFs/nJflzg0xj3I+m4vWpYzx883FAT7+5CpbdzUN0bvMaBQgw== X-Received: by 10.159.40.135 with SMTP id d7mr40281069uad.98.1481059283780; Tue, 06 Dec 2016 13:21:23 -0800 (PST) From: Bart Schaefer Message-Id: <161206132136.ZM31929@torch.brasslantern.com> Date: Tue, 6 Dec 2016 13:21:36 -0800 In-Reply-To: <67542.1481045399@hydra.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: completion files sensitive to user options like RC_QUOTES" (Dec 6, 6:29pm) References: <20161206142754.GA12824@cventin.lip.ens-lyon.fr> <161206085722.ZM31320@torch.brasslantern.com> <67542.1481045399@hydra.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: completion files sensitive to user options like RC_QUOTES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 6, 6:29pm, Oliver Kiddle wrote: } Subject: Re: completion files sensitive to user options like RC_QUOTES } } Bart wrote: } > The intention is that completion files will be auto-loaded from the } > completion system after _main_complete has started, where they will be } > affected by the set of options that it controls. } } _comp_options+=( NO_rcquotes ) } foo ' -> 'don'\''t' OK, that's a reasonable counter-argument to my patch. } In the early days, _comp_options was intentionally kept minimal. } It contains a lot more than it used to so I worry that we've already } broken things in some areas. There would be a case for wrapping the "eval" expressions in _expand with temporary restoration of $_comp_caller_options, because of the effects of NO_ksharrays etc. There might be a few other similar situations. } The quoting is internal to the C code so shouldn't look at } _comp_caller_options. We'd need to add some sort of hook We have the "sticky emulation" mechanism. Entry to completion could save the current option state before invoking the user-defined code, and then compadd could temporarily revert to that saved state. We could also add another builtin (compopts?) to manage it explicitly, though the state would still need initial capture. On a side note, maybe we need a special keyword for "emulate" that means "make sticky whatever the current options are" -- right now you would have to spell that out explicitly, relative to some base emulation such as zsh or sh.