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