From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id TAA29353 for ; Sun, 21 Jul 1996 19:29:47 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id FAA09622; Sun, 21 Jul 1996 05:21:50 -0400 (EDT) Resent-Date: Sun, 21 Jul 1996 05:21:50 -0400 (EDT) From: Zefram Message-Id: <6695.199607210920@stone.dcs.warwick.ac.uk> Subject: More thoughts on emulation To: zsh-workers@math.gatech.edu (Z Shell workers mailing list) Date: Sun, 21 Jul 1996 10:20:53 +0100 (BST) X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]7841.94 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8tVtT1.0.GM2.jQVyn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1729 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu It seems that we want to treat the emulation mode as a special type of option. When I added the settable emulation mode, its only purpose after initialisation was to select which set of option letters would be used; if my FUNCTION_ARGZERO and SH_FILE_SUBST patches are applied, that's still the case. But as we only have two sets of option letters, and that isn't likely to change in the forseeable future, it might as well be controlled by a(nother) normal option. This would immediately make it subject to LOCAL_OPTIONS, as well as all the existing option setting/testing mechanisms. Then emulate could go back to having its original one-time effect of merely setting options -- including this new one. What do you think? -zefram