zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: PATCH: sticky emulation
Date: Wed, 11 Feb 2009 18:23:06 -0800	[thread overview]
Message-ID: <090211182307.ZM9877@torch.brasslantern.com> (raw)
In-Reply-To: <20090211202840.000b37aa@pws-pc>

On Feb 11,  8:28pm, Peter Stephenson wrote:
}
} I'll submit the lot and it can be modified later if necessary.

Documentation nit:  My info-viewer and my emacs both display the list
of emulate rules like so:

     The documentation above is typically sufficient for the intended
     purpose of executing code designed for other shells in a suitable
     environment.  More detailed rules follow.
    1.
          The sticky emulation environment provided by `emulate SHELL
          -c' is identical to that provided by entry to a function
          marked for sticky emulation as a consequence of being defined
          in such an environment.  Hence, for example, the sticky
          emulation is inherited by subfunctions defined within
          functions with sticky emulation.

    2.
          No change of options takes place on entry to or exit from
          functions that are not marked for sticky emulation, other
          than those that would normally take place, even if those
          functions are called within sticky emulation.

(and so on with the floating numbers one line up and one character too
far "outdented").

I compiled this and started poking around and immediately encountered
an interesting side-effect.  Consider the function "allopt" which is
autoloaded and dumps out a list of the options and their states.

Starting from

% emulate sh -c "allopt"
(list of options appears as expected, with "sh" states)
zsh: allopt: function not defined by file

OK, clearly allopt should be getting "autoload -z" treatment.  (Aside:
Does the doc really not explain "autoload -z" anywhere?  Have I just
missed it?)

On reflection the rest of what follows is exactly as I should have
expected it to be, but having rambled on writing it all down I'm
going to send it anyway.

Exit and start a new shell, try this:

% emulate sh -c "ao() { allopt; }"
% ao
(list of options appears as expected, with "sh" states)
zsh: allopt: function not defined by file
% allopt
(list of options appears with zsh states)

Exit and start again:

% autoload -z allopt
% emulate sh -c "allopt"
(list of options appears as expected, with "sh" states)
% allopt
(list of options appears with zsh states)

Exit and start again:

% unfunction allopt
% emulate sh -c "autoload -z allopt; allopt"
(list of options appears as expected, with "sh" states)
% allopt
(list of options appears with zsh states)

So there's no way to cause an autoloaded function to acquire sticky
emulation, which is what's meant by "No special handling for ...
autoload."

-- 


      parent reply	other threads:[~2009-02-12  2:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10 23:03 Peter Stephenson
2009-02-11  3:18 ` Bart Schaefer
2009-02-11 20:28   ` Peter Stephenson
2009-02-11 23:37     ` Bart Schaefer
2009-02-12  9:44       ` Peter Stephenson
2009-02-12 10:10         ` Oliver Kiddle
2009-02-12 15:30           ` Peter Stephenson
2009-02-12 15:41           ` Bart Schaefer
2009-02-12 15:32         ` Bart Schaefer
2009-02-12  2:23     ` Bart Schaefer [this message]

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=090211182307.ZM9877@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /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).