From: Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>
To: zsh-workers@sunsite.dk
Subject: Re: [PATCH] Proposal: stat -> zstat
Date: Sun, 6 May 2007 07:00:00 -0700 [thread overview]
Message-ID: <20070506140000.GA80030@redoubt.spodhuis.org> (raw)
In-Reply-To: <200705061157.l46BvISQ003772@pwslaptop.csr.com>
On 2007-05-06 at 12:57 +0100, Peter Stephenson wrote:
> I'd still prefer a general solution along the lines of the feature
> mechanism, which requires (as far as I can see) no kludging or removal
> of anything, but I have had absolutely no response to that.
Well, I like it. FWIW.
Sorry, kept quiet because I couldn't see anything wrong with the idea
and I wasn't volunteering to do the coding. ;-)
Oh, and because I've been contaminated by Perl so I'm use to:
use Foo::bar qw/:DEFAULT :wibble -froz/;
so your proposal fits neatly with my mental models and is actually
simpler, since it doesn't have tagged groups of things to
enable/disable. Except insofar as the features-named-with-conventions
would let you do just that.
Is it worth adding to the spec that the features will be processed
left-to-right, so that interactions between features will work? Eg,
disable all except certain aspects? Most modules will never use this,
thankfully.
zmodload -F zsh/pcre -:builtins :condops
zmodload -F zsh/files :files -mv :fs
(hypothetically putting "sync" in an ":fs" category)
And yes, the : as a part of the name instead of a separator is
distinctly un-shell-like, I use it here only so that those similarly
afflicted will understand what I mean.
On the other hand, arguing devil's advocate, what would the feature
infrastructure provide that's not already available via zsh/parameters
and use of enable/disable?
Perhaps, evil thought, if feature-set changes could be tied to a
function in the same way as localoptions lets you emulate ... then this
would definitely provide cleaner start-up and functions could then just
explicitly declare their dependencies .... how much overhead would there
be for this? I'm not sure how much complexity this introduces for
little gain.
</brain-dump><sleep>
next prev parent reply other threads:[~2007-05-06 14:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-03 5:39 Phil Pennock
2007-05-03 8:50 ` Peter Stephenson
2007-05-06 1:07 ` Phil Pennock
2007-05-06 11:57 ` Peter Stephenson
2007-05-06 14:00 ` Phil Pennock [this message]
2007-05-07 0:58 ` Peter Stephenson
2007-05-03 14:48 ` Bart Schaefer
2007-05-03 15:46 ` Peter Stephenson
2007-05-07 5:31 ` Bart Schaefer
2007-05-08 14:40 ` Peter Stephenson
2007-05-09 17:19 ` Bart Schaefer
2007-05-09 17:47 ` Peter Stephenson
2012-06-29 9:40 4.3.17 unset RPS1 vs RPROMPT Phil Pennock
2012-06-29 10:02 ` Mikael Magnusson
2012-06-29 13:32 ` Phil Pennock
2012-06-29 17:35 ` Bart Schaefer
2012-06-29 18:52 ` Peter Stephenson
2012-06-30 5:05 ` Phil Pennock
2012-06-30 17:31 ` Bart Schaefer
2012-07-01 17:39 ` 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=20070506140000.GA80030@redoubt.spodhuis.org \
--to=zsh-workers+phil.pennock@spodhuis.org \
--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).