zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: Zsh workers <zsh-workers@zsh.org>
Subject: Re: autoload -X inside an anonymous function
Date: Fri, 5 Oct 2012 22:32:28 +0100	[thread overview]
Message-ID: <20121005223228.408a7b2f@pws-pc.ntlworld.com> (raw)
In-Reply-To: <120924115023.ZM22732@torch.brasslantern.com>

On Mon, 24 Sep 2012 11:50:23 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 20,  8:35pm, Peter Stephenson wrote:
> }
> } I discovered while doing this that "autoload +X _path_files" didn't
> } work, it doesn't like the absence of the semicolon in the braces.  If
> } anyone wants to work out why, be me guest.
> 
> Works for me with 4.3.17-test-2 ... and also with 5.0.0-dev-0 just now
> compiled from CVS (edited _path_files to remove your semicolon again).
> 
> Did you try autoload -z +X ?

I've tracked this mystery down... I had "ignoreclosebraces" set because
I had been trying it out from when the option was added.  This is
correctly turned off by the completion code, but it caused loading of
_path_files outside the completion code to fail.

However, this opens a can of worms, or reveals an open can of worms, or
at least perturbs the wave function of the universe sufficiently that
measurement reveals the can of worms to be in the opened state.  (I can,
however, understand that Schroedinger's Cat is likely to remain more
popular than Stephenson's Wormcan.)  Sorry, it's Friday evening.

Naively, you might have thought that simply making ignoreclosebraces an
emulation setting (which might be the right thing to do anyway, as
below) would fix this, but actually we seem to be missing a trick: the
-z flag *doesn't* put the shell into zsh emulation during the load,
although the manual does confusingly use the word "emulation" to
describe its effect.  Furthermore,

  emulate zsh -c 'autoload -z stuff'

(where stuff is a function relying on being able to omit the semicolon
before a closing brace) doesn't work, although

  emulate zsh -c 'autoload +X -z stuff'

does work, because the function is loaded while the emulation is still
in effect.  More explicitly, the emulate in this case is only "sticky"
for functions declared in it, not for functions marked for autoload in
it.  Maybe this needs to change?  I explicitly did it this way:

	    /* No sticky emulation for autoloaded functions */
	    shf->emulation = 0;

and I wrote in the accompanying message (zsh-workers/26546):

  Note that sticky emulation is not propagated to autoloaded functions,
  neither when the autoload is set up nor when they are loaded, nor does
  autoloading a function provide the same sort of firewall as sticky
  emulation.  Defining a function with the special "functions" parameter
  is treated the same as defining a function inline in the normal way.

but I'm not sure I thought this through properly.  If I got it wrong,
the fix for the case here is trivial (and I've verified it works).
The more I think about it, the less I can think of a good reason for
having an autoload declared within a sticky emulation lose the
stickiness.

Beyond that, I'm not sure what the answer is; is making -z force zsh
emulation reasonable?  I don't necessarily think making -k force ksh
emulation is reasonable, the function might be a zsh function that just
happens to be written using the ksh format for autoloads.

I may simply be expecting too much, though it would certainly be good to
be able to ensure a function can be loaded irrespective of the options
currently in effect.

On the whole I'd be inclined to reverse my decision not to propagate
stickiness to autoloads, and to document that -z only affects the
autoload style and that

  emulate zsh -c 'autoload -Uz ...'

is the way to ensure functions are loaded with appropriate options.
This generalises in a natural way to other emulations in a way
overloading the -z flag doesn't.

Index: Src/options.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/options.c,v
retrieving revision 1.62
diff -p -u -r1.62 options.c
--- Src/options.c	21 Aug 2012 18:03:03 -0000	1.62
+++ Src/options.c	5 Oct 2012 21:02:18 -0000
@@ -160,7 +160,7 @@ static struct optname optns[] = {
 {{NULL, "histverify",	      0},			 HISTVERIFY},
 {{NULL, "hup",		      OPT_EMULATE|OPT_ZSH},	 HUP},
 {{NULL, "ignorebraces",	      OPT_EMULATE|OPT_SH},	 IGNOREBRACES},
-{{NULL, "ignoreclosebraces",  0},			 IGNORECLOSEBRACES},
+{{NULL, "ignoreclosebraces",  OPT_EMULATE},		 IGNORECLOSEBRACES},
 {{NULL, "ignoreeof",	      0},			 IGNOREEOF},
 {{NULL, "incappendhistory",   0},			 INCAPPENDHISTORY},
 {{NULL, "interactive",	      OPT_SPECIAL},		 INTERACTIVE},

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/


  reply	other threads:[~2012-10-05 21:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18  2:12 Oliver Kiddle
2012-09-18 16:58 ` Bart Schaefer
2012-09-19  0:35   ` Bart Schaefer
2012-09-19  2:28   ` Oliver Kiddle
2012-09-19 14:58     ` Bart Schaefer
2012-09-20 19:35       ` Peter Stephenson
2012-09-24 18:50         ` Bart Schaefer
2012-10-05 21:32           ` Peter Stephenson [this message]
2012-10-05 21:54             ` Christian Neukirchen
2012-10-07 17:51               ` Peter Stephenson
2012-10-05 22:24             ` Peter Stephenson
2012-10-06  7:56             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121005223228.408a7b2f@pws-pc.ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).