Re: PATCH: compadd (+ questions)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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