"Bart Schaefer" wrote: > * Partial word motions in the face of mixed case, i.e. move the cursor to > the next/previous capital letter InMixedCaseWordsLikeThisOne, including > deletions that treat words this way. This is also handled by adding a > few new ZLE builtins, and relies on isupper() to detect upper case, so > it may behave differently in different language locales. > > My first inclination was to think that this should be handled with the > WORDCHARS variable, but of course WORDCHARS adds other characters that > are treated as alphanumeric; there's no way to say that upper case > letters should -not- be treated as alphanumeric. I guess I'd prefer a > patch that handled wordchar-exlusions more generically (without adding > builtins) and I may even look at adding such a thing. > > For this patch to go into 3.0.6, I'd want PWS to agree that the new ZLE > builtins would appear in 3.1.6, too. Well, in 3.1 you can do more sophisticated things by altering $CURSOR with widgets already, so new builtins are not really necessary. Furthermore, getting a complete set of functions with this alternative word behaviour looks a slightly wasteful way of doing it (and if it's an incomplete set of functions, I guarantee it won't have the one you want). But it would be nice to have some advance on $WORDCHARS, which has always frustrated me (I always wanted to be able to specify characters which *shouldn't* be parts of words, since $WORDCHARS is too long for me to see easily what's not in it --- and how else can I tell the code that only spaces should delimit words; and why does the default include =, - and / but not +; parentheses but not |? Etc.). Perhaps the solution to the problem in question is to add a variable $WORDSTART giving a list of characters with this behaviour, and the corresponding macro iwords(). It could allow ranges, so you can add "A-Z"; the change to inittyptab() to allow that isn't too drastic --- the change to zle_word.c is the hairy one. That's less sophisticated w.r.t. locales, unfortunately; you'd have to add ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ by hand, which is a little unpleasant. An alternative is to allow A to stand for all upper case, 1 for all digits, etc; or to allow escape sequences, so \\ -> backslash, \U -> uppercase, etc (that's perhaps the neatest). I don't see an easy way of avoiding a new variable by enhancing $WORDCHARS, since in principle anything can appear in that. You could, say, have a list of possible initial characters after two spaces, but it's a bit of a mess. Perhaps, if my frustrations above are widespread, there's room for a variable $NONWORDCHARS, too. That's easy to add: by default it's not set, and if it is it takes precedence over $WORDCHARS in inittyptab() so that anything not in it is made a word character; no editing code needs to change. Can this be made to the job of $WORDSTART? It seems to me not, since forward-word puts the cursor *after* the non-word character, which isn't what you want with special initial characters (they're behaving more like special final characters, in fact). -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy