From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: compadd (+ questions)
Date: Thu, 11 Feb 1999 10:25:53 -0800 [thread overview]
Message-ID: <990211102553.ZM3491@candle.brasslantern.com> (raw)
In-Reply-To: <199902110909.KAA05147@beta.informatik.hu-berlin.de>
In-Reply-To: <9902110911.AA53573@ibmth.df.unipi.it>
In-Reply-To: <199902110938.KAA05365@beta.informatik.hu-berlin.de>
On Feb 11, 10:11am, Peter Stephenson wrote:
} Subject: Re: PATCH: compadd (+ questions)
}
} Sven Wischnowsky wrote:
} > > Some way of supplying options to
} > > new-completion-examples would be good.
} >
} > I don't understand what kind of options you mean here.
}
} Sorry, I wasn't clear about that. I meant that if people are going to
} be using whatever-it's-going-to-be-called more or less en bloc, it
} would be helpful to have ways of telling it whether or not to bind the
} widgets it's just defined (and maybe other things like that).
} However, since it's almost certainly going to be sourced, it's hard to
} supply options in a simple way.
Eh?
zsh% source =(echo 'echo $0: $*') these are the args
/tmp/zsha00834: these are the args
} I, too, found the new [[-tests a little confusing at first sight. I'm
} inclined to think maybe they should be limited to those that can't be
} done so easily in the standard way. For example, I don't see why
} people shouldn't use (( NMATCHES )) rather than [[ ! -nmatches 0 ]] .
} But I haven't really got a proper grip on using this yet.
This is what I'm thinking, too. I may be getting my chronology confused,
but wasn't it the case that the new condition codes showed up before all
the variables for NMATCHES and CURRENT etc. were available?
There's a short list of stuff you can't easily do with the variables:
1. Automatic shifting of bits of PREFIX into IPREFIX, as -iprefix does
and as -string and -class do with two args.
2. Adjusting the range of words used, as -position does with two args.
3. Skipping exactly N occurrences of an embedded substring, as -string
and -class do with two args.
Have I missed any others? Sven didn't answer my question about whether
the remaining condition codes are faster or have other side-effects:
On Feb 11, 10:38am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: compadd (+ questions)
}
} Bart Schaefer wrote:
}
} > I think the worst are the new switches for the conditional expressions,
} > particularly the ones that take two following strings; it looks wrong.
} > I just spent several minutes pondering whether [[ -word CURRENT-1 -ef ]]
} > would look better to me than [[ -current -1 -ef ]], and decided it's
} > only marginally better. It using -current or -word a lot faster than
} > using [[ $@[CURRENT-1] == '-ef' ]]? Are they doing some other magic?
Sven?
The point being that, although being able to add conditions in modules is
a cool thing, perhaps we should drop the ones that are easily replicated
using simple tests on the variables, and then look again at the rest to
see if there's a better way to express them.
Unless there's a reason not to, such as, interpolating the string values
of the variables during parsing of the expression is significantly slower
than recognizing the new codes themselves (which I don't know whether or
not is the case).
} For really clean completion functions we would need a new control
} structure to be able to put all tests into one function and having
} everything reset to the previous state automatically. Doing something
} like:
}
} if comptest iprefix '-'; then
} ...
} compreset
} else
}
} wouldn't be that easy to glark, too.
I still think the right way to do this is with shell-function scoping.
tryprefix () {
complocal # Equivalent of "local CURRENT NMATCHES ...",
# if "local" worked on special parameters
comptest ignored-prefix $1 && { shift ; "$@" }
}
tryprefix - complist -k "($signals[1,-3])"
The unfortunate thing about this is that it clashes with $argv holding
the command line (but that's true of any function called from within the
top-level main-complete function, isn't it?). There should probably be
another array that also holds the words, but I guess it isn't that hard
to have the main completion function set up a global for it.
Looking at the above gives me a nagging idea ... it's half-formed at the
moment, but it goes something like this ...
The effect of `compsave; [[ -iprefix ... ]] ; compreset` is that we want
to try a completion with a particular prefix and if that fails, start
over with the original state and try again. Similarly for -position to
limit the range of words, etc.
So why don't we actually DO that? That is, make a "recursive" call to
the whole completion system? Add -iprefix, -position, -string, -class
options to "compcall" (or some similar new command) and have THAT adjust
the variables, re-invoke the appropriate main completion function, and
then restore everything if that function returns nonzero. It would then
be an advertized side-effect of compcall that, if it returns nonzero,
the state of the completion variables has been adjusted -- which makes a
lot more sense to me than having a conditional do it.
Then most if not all of the completion-related conditionals can go away.
However, I don't really understand yet the interaction of (say) adding
matches for menucomplete that rely on a prefix in one place, and adding
more matches for the same completion in another place that rely on a
different prefix, with the state of the completion variables in both
places. Maybe the variables should simply ALWAYS be restored when the
recursive compcall unwinds; or maybe there's some other interaction that
makes this whole idea unworkable.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-02-11 18:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-11 9:09 Sven Wischnowsky
1999-02-11 9:11 ` Peter Stephenson
1999-02-11 9:38 ` Sven Wischnowsky
1999-02-11 18:25 ` Bart Schaefer [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-02-18 15:22 Sven Wischnowsky
1999-02-12 13:39 Sven Wischnowsky
1999-02-12 10:32 Sven Wischnowsky
1999-02-12 8:42 Sven Wischnowsky
1999-02-13 19:19 ` Bart Schaefer
1999-02-01 9:10 PATCH: compadd Sven Wischnowsky
1999-02-10 16:26 ` PATCH: compadd (+ questions) Peter Stephenson
1999-02-11 7:50 ` 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=990211102553.ZM3491@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--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).