Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
- X-seq: zsh-workers 9869
 
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
 
- To: zsh-workers@xxxxxxxxxxxxxx
 
- Subject: Re: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
 
- Date: Thu, 24 Feb 2000 18:08:52 +0000
 
- In-reply-to: <200002240907.KAA32439@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
 
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
 
- References: <200002240907.KAA32439@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
 
On Feb 24, 10:07am, Sven Wischnowsky wrote:
} Subject: RE: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
}
} 
} Andrej Borsenkow wrote:
} 
} > zcodeload file
Let's not do that, shall we?  Let's stick with autoload and have a file
suffix convention, like emacs' .el and .elc, or something.  Heck, there
could even be separate fpath and compiled_fpath or ...
} All this also makes me think about a way to allow multiple zsh's to
} share other memory bits (like the command table and so on). How
} portable is anonymous shared mmap or shared mmap on /dev/null?
Do we really want to go down the road of having e.g. zmodload in one
zsh suddenly make new builtins available to another zsh?  I don't want
the behavior of a script that's running in the background to change
because of something I loaded into my foreground shell ...
-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author