Re: WORDCHARS, etc.

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

"Bart Schaefer" wrote:
> Anyway, the reason I've been staring at this for so long without answering
> is that, though your WORDSTART and NONWORDCHARS suggestions are reasonable,
> there's something about that approach that doesn't feel quite right.  The
> trouble is, I can't think of anything better without resorting to full-
> blown regular expressions (or at least glob patterns) after the manner of
> emacs.

I've had this sort of worry, too.  Maybe there's room for defining new
flags for commands, telling it (say) whether to use space-separated words
instead of WORDCHARS-defined words, which might be handled by some sleight
of hand in the macro used in zle_word, i.e. instead of testing iword() we
test !inblank() (we're approaching the limits of type flags possible with a
short if we need more).  The syntax might be that you defined a new widget
using `zle', but in a way that made it use an existing builtin function
just with those extra flags.  That would reduce the hassle to one zle and
one bindkey command.  I think this could even be done quite easily with zle
-A, where you allowed the thingy to store ZLE_* flags and used the
appropriate part of the set to override the ones in the widget (non-zle
hackers are not expected to understand that sentence). So, for example

zle -Ab transpose-words transpose-space-words

(b for blank, since it allows tab and newline too) would define a command
transpose-space-words which acts exactly the same way as transpose-words
but words are delimited by blanks.

Aliases for using uppercase-delimited words could use the same mechanism
(combined with $WORDSTART, if necessary), say `zle -As ...' (confusion
becuase b = blank or beginning, s = space or start, but I didn't invent
this crazy language).  However, that would still require rather more
surgery in zle_word.c (and in this case presumably implies the new
word-delimiters are supplementary to the usual set, so -s could be combined
with -b).

Maybe we could even use get_comp_string() to decide where the beginning of
the current syntactic word is, and hence allow a flag for that too
(particularly now it knows where the start of a string is), but I don't
think I want to contemplate full sexp handling this side of the millenium
(3001, I mean).

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy