From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20393 invoked from network); 6 Jun 1999 14:42:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Jun 1999 14:42:29 -0000 Received: (qmail 13884 invoked by alias); 6 Jun 1999 14:42:11 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2358 Received: (qmail 13873 invoked from network); 6 Jun 1999 14:42:10 -0000 Message-Id: <9906061413.AA22155@ibmth.df.unipi.it> To: zsh-users@sunsite.auc.dk Subject: Re: Call for opinions on a couple of prospective zsh patches In-Reply-To: ""Bart Schaefer""'s message of "Sun, 06 Jun 1999 06:51:50 DFT." <990606065150.ZM9165@candle.brasslantern.com> Date: Sun, 06 Jun 1999 16:13:38 +0200 From: Peter Stephenson "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