From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
zsh-workers@sunsite.auc.dk
Subject: Re: Default fpath
Date: Mon, 13 Mar 2000 16:52:00 +0000 [thread overview]
Message-ID: <1000313165200.ZM2467@candle.brasslantern.com> (raw)
In-Reply-To: <200003131042.LAA17110@beta.informatik.hu-berlin.de>
On Mar 13, 11:42am, Sven Wischnowsky wrote:
} Subject: Re: Default fpath
}
} Bart Schaefer wrote:
}
} > Note 1 -- While we're on the topic of zcompile, it could use:
} > (1) a way to append to an existing .zwc, rather like `ar' works, and
}
} That's a bit problematic because of the little/big-endian thing. I.e. we
} can't just append to a wordcode file (and I don't want to have
} multiple headers).
I was afraid of that.
} But of course we could make it read/change/re-write
} such files, also allowing deletion of functions. Is it worth it? I
} mean, creating wordcode files is quite fast for me...
Perhaps not. Actually, what would suit me fine is a way to dump out a
.zwc of (a subset of the) functions defined in a running zsh.
} > (2) an option to say whether each function should be autoloaded zsh-style
} > or ksh-style, so that the right thing happens regardless of the run-
} > time setting of kshautoload.)
}
} But currently it is the same as for loading from a normal file,
} wouldn't it probably be confusing if the wordcode file said how to
} load it?
Actually I'd like it if the text file could "say how to load it" as well,
but that wouldn't be portable -- the whole point of kshautoload is to be
able to write functions that can load into both zsh and ksh. So if I set
kshautoload, I'm probably in a situation where I load ksh functions. It
would be possible to require that zsh function text files include some
token that specifies NOT using kshautoload, but that would put the burden
on the ordinary zsh writer, which feels wrong.
There's no such problem with .zwc files -- only zsh will load them, and
the how-to token is invisible to the user.
Consider the current problem of initializing the completion system with
kshautoload set. (I.e., you can't.) The kshautoload user could solve
this problem by precompiling the completion system for zsh loading.
The one thing I can't decide is whether the default should be initialized
from the setting of kshautoload, or if it should always default to zsh.
} But don't get me wrong: I never use kshautoload, so I
} wouldn't be against allowing it. Per-function or per-wordcode file?
Per source file used to build the wordcode file would be the correct
granularity, which I guess means per-function?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~2000-03-13 16:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-13 10:42 Sven Wischnowsky
2000-03-13 16:52 ` Bart Schaefer [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-03-15 15:57 Sven Wischnowsky
2000-03-15 18:15 ` Bart Schaefer
2000-03-15 9:32 Sven Wischnowsky
2000-03-14 10:19 Sven Wischnowsky
2000-03-14 17:55 ` Bart Schaefer
2000-03-11 21:29 Oliver Kiddle
2000-03-11 23:46 ` 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=1000313165200.ZM2467@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.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).