Re: WORDCHARS, etc.

Re: WORDCHARS, etc.

[Sven Wischnowsky]

Peter Stephenson wrote:

> 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).

The more I read about this the more I think that we should just go
ahead and allow all zle widget functions to get (an arbitrary number
of) arguments (strings). If no arguments are given, the function uses
its defaults. We could than probably have a couple of generic
functions (e.g. for word movement) and define aliases to them with
fixed arguments (as Peter suggested with flags), probably even for
some of the functions that are currently real builtin widgets.

I mean, we were talking about allowing arguments for the search-
functions anyway, so why not use it it many more places.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: WORDCHARS, etc.

[Peter Stephenson]

"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@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy