Re: New configuration -- should we...

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Nov 11, 11:24am, Sven Wischnowsky wrote:
} Subject: New configuration -- should we...
}
} [Maybe you'll all think that I have now gone completely mad...]

Was that a pun?

} Bart once said that if you have a programming language, don't implement 
} a second one -- and somehow the new completion system came into
} existence.

Apparently I need to listen to myself more often.

} The completion system finds out the context in which completion is
} attempted. This is a process in multiple steps, the overall context is 
} found using the `#compdef' stuff. The function thus then probably
} knows about other finer-grained contexts. In each of these contexts
} one or more types of matches can be generated. This is the place where 
} `_tags' is used.

Here's a viewpoint that just occurred to me, and that might be helpful:

The shell itself knows syntactic contexts.  These are represented by
the special `-context-' tokens.  The shell also knows that when the
`-command-' context is "filled in" (needs no further completion), it then
implies a particular semantic context (completing the arguments of the
specific command).  #compdef maps the contexts the shell knows about to
the functions that generate matches for those contexts.

Superficially, every such function is different, because the semantics
of every `-context-' and every command differ from the others (if they
didn't, you wouldn't need to handle them individually).  However, the
very nature of interactions with filesystems and environments means that
there are lots of overlaps in those semantics.  (Otherwise the old
compctl system, and completion in other shells, wouldn't work at all.)
The idea behind _tags is to give names to those overlapping regions, and
to organize them when more than one applies in any given situation.

Now:
 
} Instead of using some internally held configuration state we could
} simply make `_tags' call a user-supplied function which gets the tags
} supported in the current context and then has to `sort' them.

I like this approach because it separates the "naming" function of _tags
from the "ordering" function.  That is, the current syntax for a tag
represents a data structure that simultaneously maps a name to an action
and a name to a priority.  This new suggestion allows the tag syntax to
bear only one of those burdens -- mapping name to action -- and leaves
it up to the user-supplied function to do the ordering.

There's still the issue of parameterizing the action, which is what the
"style" part of the tag syntax accomplishes.  Your second suggested
implementation makes this explicit, which I like (though prefixing them
with hyphens to look like options may not be necessary).

One further thought, at the risk of distraction:  Aren't these tags just
describing more contexts?  That is, what we're really trying to do is
split the whole system into stages: (1) determine context, (2) generate
appropriate matches, (3) organize matches for display.  The farther apart
we can drive these, the better; maybe there's even some way to cause the
tags to become context-keys for _normal, or the equivalent?

The trick is to balance the way zsh wants to organize things -- as the
three stages above, each separately parameterized -- with the way users
want to understand/express it, which is [*] first by generic behavioral
preference for each "overlapping region" and second in large chunks by
outermost context (i.e. per command).

[*] As I see it.

} There are two ways how we could make that function be called. Either
} we do it only on the first call to `_tags' or on every call. The
} latter would probably be more general but the first one presumably
} would be easier when writing such a config function.

I would think this really boils down to a computation-vs-memory tradeoff.
That is, do you want to compute the mapping once and store it forever, or
recompute it every time to save the storage?  The function itself should
not need to be significantly different either way, should it?

} For the way how the config function says which tags are to be used I
} currently see two possibilities (well, more than two, but these are
} the easiest I see). In both cases the config function is only called
} when `_tags' is called with the tags for the current state as
} arguments, not when it is called to get the next set of tags to try.

Thus separating "determine context and organize display" from "generate
matches."  Can you see a way to separate the first two, as well?

} 2) The second way is based on support from `computil' (in a first
}    implemention-to-play-with it could be entirely in shell code).

I like this so much better that I've ignored your first suggestion.

}    There could also be support to easliy set the pure config-tags,
}    i.e. the pseudo tags we add as a replacement for the config keys we 
}    have now. I haven't yet thought too much about that part.

Config keys / pseudo tags are the user's expression of generic behavioral
preference.  Maybe the right way to think of them is as global defaults
for the comptry arguments, which can then be overridden locally by each
config function?  (Your follow-up in 8626 makes me think you're thinking
this way, too.)

}    Only so
}    much: with support by C-code it would almost certainly be easy
}    enough to allow really arbitrary types for them. E.g. we could make 
}    them be reported as strings, arrays, and assocs. With that it would
}    even be possible to use the same mechanism to replace some (or
}    all?) of the parameters we use now. This is especially interesting
}    for things like the `COMMAND_hosts_ports_user' because for the
}    `COMMAND' part we could use the context-switching this
}    configuration stuff is all about anyway. I /think/ this would make
}    it easier for users.

I think this is looking in the right direction, but I can't think deeply
enough into it at this point to be sure.

} Ok, the more I think about this, the more I like it.

Yes.

} Also, someone please tell me if this is too complicated for the average 
} user. Is something like `conf2' really easier to understand?

See my "The trick is ..." paragraph above.

} Or does anyone have suggestions for, e.g. builtins or helper functions 
} that would allow us to make the config funcs better readable or
} understandable?

I don't yet ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com