zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: While we're on the subject of zcompile ...
Date: Tue, 13 Apr 2004 05:32:46 +0000	[thread overview]
Message-ID: <1040413053246.ZM20004@candle.brasslantern.com> (raw)
In-Reply-To: <3571.1081806187@athlon>

On Apr 12, 11:43pm, Oliver Kiddle wrote:
}
} Bart wrote:
} 
} > Matthias has since written back to me again and says he's having all
} > sorts of problems with zcompile'd functions
} 
} I've had problems with it in the past so it probably needs more
} investigation.

I find the behavior of "zcompile -a" (with no arguments) to be extremely
annoying.  There should be a way to say "dump all the functions you can,
and ignore the ones that are already loaded or can't be loaded" rather
than having it die entirely (blowing away the dump done so far) the first
time it encounters an un-dumpable function.

For one thing, if I've said "zcompile -a" with no arguments, then the
chances are pretty good that I didn't intend for it to even try to dump
already-loaded functions; if I wanted both, I'd have used "-c -a".  For
another, there's no way to tell in advance whether a function is going
to fail to autoload, so it's practically impossible to create a list of
names to pass as arguments.

The questions are whether it's cur_add_func() that should be taught to
ignore the error, or build_cur_dump(), and whether it should happen any
time there are no arguments, or there should be a flag to cause errors
to be ignored.


  reply	other threads:[~2004-04-13  5:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-10 17:44 Compsys and KSH_AUTOLOAD Bart Schaefer
2004-04-12 14:00 ` Oliver Kiddle
2004-04-12 15:59   ` Bart Schaefer
2004-04-12 21:43     ` Oliver Kiddle
2004-04-13  5:32       ` Bart Schaefer [this message]
2004-04-17 21:08         ` While we're on the subject of zcompile Oliver Kiddle
2004-04-13  5:38       ` Compsys and KSH_AUTOLOAD Bart Schaefer
2004-04-13 15:29         ` PATCH: " Oliver Kiddle
2004-04-13 17:51           ` Bart Schaefer
2004-04-16 16:49             ` Oliver Kiddle
2004-04-16 17:25               ` Bart Schaefer
2004-04-18 13:46                 ` Oliver Kiddle
2004-04-16 17:30               ` Bart Schaefer
2004-04-17 19:51                 ` Oliver Kiddle
2004-04-19  0:14                   ` Bart Schaefer
2004-04-19 10:18                     ` Oliver Kiddle
2004-04-20  4:11                       ` Bart Schaefer
2004-04-20 10:08                         ` Oliver Kiddle
2004-04-14  5:04           ` Bart Schaefer
2004-04-14 19:55 ` Peter Stephenson

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=1040413053246.ZM20004@candle.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).