From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-22418-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27267 invoked by alias); 24 Jan 2017 19:38:50 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 22418
Received: (qmail 28638 invoked from network); 24 Jan 2017 19:38:50 -0000
X-Qmail-Scanner-Diagnostics: from 195.159.176.226 by f.primenet.com.au (envelope-from <gcszu-zsh-users@m.gmane.org>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(195.159.176.226):SA:0(1.3/5.0):. 
 Processed in 1.607622 secs); 24 Jan 2017 19:38:50 -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=1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	RDNS_NONE autolearn=no autolearn_force=no version=3.4.1
X-Envelope-From: gcszu-zsh-users@m.gmane.org
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: none (ns1.primenet.com.au: domain at m.gmane.org does not designate permitted sender hosts)
X-Injected-Via-Gmane: http://gmane.org/
To: zsh-users@zsh.org
From: Martin Vaeth <martin@mvath.de>
Subject: Re: Avoiding the zshells intelligence...in one case
Date: Tue, 24 Jan 2017 19:37:45 +0000 (UTC)
Message-ID: <slrno8fb8e.3dr.martin@lounge.imp.fu-berlin.de>
References: <20170122080153.GA5042@solfire>
 <alpine.LRH.2.00.1701220936420.4560@toltec.zanshin.com>
 <slrno8aadl.dbe.martin@lounge.imp.fu-berlin.de>
 <alpine.LRH.2.00.1701221437530.4560@toltec.zanshin.com>
 <slrno8chmt.58s.martin@lounge.imp.fu-berlin.de>
 <alpine.LRH.2.00.1701231438190.4560@toltec.zanshin.com>
Reply-To: martin@mvath.de
X-Complaints-To: usenet@blaine.gmane.org
User-Agent: slrn/pre1.0.0-26 (Linux)

Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> You could try this, but it's potentially risky:
>
> re_nomatch() { { ${~@} } always { setopt nomatch } }
> alias t='setopt nonomatch && noglob re_nomatch echo'

Why is this risky? Because it can leave nomatch in the wrong state?
The following does not have this problem and also takes the other
settings you mentioned into account:

unsetopt_nomatch() {
	if unsetopt | grep -q nonomatch
	then	restore_nomatch() setopt nomatch
	else	restore_nomatch() :
	fi
	unsetopt nomatch
}
noexpand_restore_nomatch() { {
() {
	setopt local_options no_nullglob n_ocshnullglob
	${~@}
} $@ } always {
	restore_nonomatch
	unfunction restore_nomatch
} }
alias noexpand='unsetopt_nomatch; noglob noexpand_restore_nomatch '

Example usage: alias wget='noexpand wget'

It is clumsy, because the "setopt nomatch" must possibly be excluded from
the "localoptions" range; except for using an anonymous function
and passing the arguments to it, I did not find another solution...
To get correct completion for the above alias, I guess you also have to

compdef noexpand_restore_nomatch=noglob

after the initialization of the completion system.