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

WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches)

[Bart Schaefer]

On Jun 6,  4:13pm, Peter Stephenson wrote:
}
} 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 [...]).
} 
} Perhaps, if my frustrations above are widespread, there's room for [...]

I've had this message sitting in my editor for three days now trying to
decide what to say about it.  I share some of your frustrations; I always
forget that WORDCHARS doesn't mean the opposite of what it does until I
actually want to try something with it, and then I get annoyed.

My biggest complaint is that I always want {,backward-}kill-word to treat
path components as separate words, but I usually want transpose-words to
treat entire paths as a single word.  (I tried vi-backward-kill-word, but
it stops both before and after killing each individual / character, which
drives me nuts.)  Yes, in 3.1.5-pws-* I can rewrite the widgets to do it,
but it's always seemed that it ought to be easier.  (Now that I've said
that, I note that it's probably off-topic.)

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.

The gist is that I'm with you, but not in a very helpful way just yet.

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

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