* Call for opinions on a couple of prospective zsh patches
@ 1999-06-06 6:51 Bart Schaefer
1999-06-06 13:36 ` Adam Spiers
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Bart Schaefer @ 1999-06-06 6:51 UTC (permalink / raw)
To: zsh-users
Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
features that could appear in zsh 3.0.6. I'm undecided whether to add
any or all of them. They are:
* Completion using "dynamic abbreviations" after the manner of the emacs
dabbrev package. This includes adding a special `dabbrev-complete' ZLE
action, along the lines of expand-or-complete, complete-word, etc.
I find the effects of `dabbrev-complete' to be -very- similar to
setopt menu_complete
compctl -D -s '${=$(history -nr 1)}'
except that it can be bound to a different key than regular completion,
it always uses menu-completion behavior regardless of the option, and
the menu is sorted in reverse time order rather than alphabetically.
The next 3.1 release will include commands to bind special user-defined
completions to separate keystrokes (in the way that expand-or-complete
can be bound to a different key than complete-word, in 3.0) and also to
associate menu behavior with individual completions and to custom-sort
the menus; so a new builtin complete action is not likely to be added in
3.1.6. I'm thus reluctant to have 3.0 branch off in a direction that
the development version won't follow. And I think that most of the
benefits of `dabbrev-complete' can be had in plain 3.0.5 by adding the
above -s ... to a few compctls, so a builtin is not strictly necessary.
* 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.
* Support for the LS_COLORS environment string, to colorize file names in
the same contexts where the LIST_TYPES option presently appends various
markers ('/' for directories, '@' for symlinks, etc.). Depends on the
terminal having color capability, obviously.
The only issue about this one is that it's borrowed from GNU copylefted
source. I don't want to include it without an exemption from the GPL,
and Greg doesn't want to pester the FSF about an exemption unless I'm
certain to include it; so we're temporarily at an impasse. If several
zsh users say they'd like to see this included, I'll tell Greg to go
ahead and request the exemption.
Please agree/disagree/comment to help me make a decision on these. Thanks.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 6:51 Call for opinions on a couple of prospective zsh patches Bart Schaefer
@ 1999-06-06 13:36 ` Adam Spiers
1999-06-06 16:20 ` Bart Schaefer
1999-06-06 14:13 ` Peter Stephenson
1999-06-06 16:50 ` Call for opinions on a couple of prospective zsh patches Stefan Monnier
2 siblings, 1 reply; 13+ messages in thread
From: Adam Spiers @ 1999-06-06 13:36 UTC (permalink / raw)
To: zsh-users
Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
> features that could appear in zsh 3.0.6. I'm undecided whether to add
> any or all of them. They are:
>
> * Completion using "dynamic abbreviations" after the manner of the emacs
> dabbrev package. This includes adding a special `dabbrev-complete' ZLE
> action, along the lines of expand-or-complete, complete-word, etc.
I submitted a patch to zsh-workers in Feb 1998 (see threads 'tcsh-like
history-based dabbrev-expand patch' and 'PATCH: complete-history')
which added history-dabbrev-expand and history-reverse-dabbrev-expand
actions, but it didn't get included because Peter had already written
a patch for zle -C, which allowed you to do something like
zle -C complete-history -H '' 0
bindkey "\M-/" complete-history
There were a few differences in functionality between the two (mine
had a reverse action, and with Peter's, the sequence M-/ TAB was
equivalent to M-/ M-/), but they were essentially the same thing.
Personally I find this feature so useful that I can't stand being
without it, and still use that version with my patch hacked in to this
day, which is unfortunate, because it's prevented me from regularly
trying out the newer development versions.
Which versions is zle -C (or similar) available in these days?
> I find the effects of `dabbrev-complete' to be -very- similar to
> setopt menu_complete
> compctl -D -s '${=$(history -nr 1)}'
> except that it can be bound to a different key than regular completion,
> it always uses menu-completion behavior regardless of the option, and
> the menu is sorted in reverse time order rather than alphabetically.
I really do relish it being bound to a different key. I think I'd
prefer not to have it if it was the choice between being bound to TAB
as a fallback completion and not having it.
Also, I don't like the idea of menu-completion behaviour, because I
tend to keep a huge history (precisely for the reason that it makes a
dabbrev-expand action so useful), so I'd end up with huge menus (or a
"do you want a huge menu" prompt) most times I hit the key. Ugh.
> The next 3.1 release will include commands to bind special user-defined
> completions to separate keystrokes (in the way that expand-or-complete
> can be bound to a different key than complete-word, in 3.0) and also to
> associate menu behavior with individual completions and to custom-sort
> the menus; so a new builtin complete action is not likely to be added in
> 3.1.6. I'm thus reluctant to have 3.0 branch off in a direction that
> the development version won't follow.
Fair point.
> And I think that most of the
> benefits of `dabbrev-complete' can be had in plain 3.0.5 by adding the
> above -s ... to a few compctls, so a builtin is not strictly necessary.
I'd say that if this next 3.1 release is coming soon then maybe don't
bother. However, I would really love to see support for this
functionality ASAP. Apart from anything else, tcsh already has it,
and we can't let tcsh have features zsh doesn't have, can we? :-)
> * 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.
I would like to see a lot more flexibility with the WORDCHARS stuff.
I'm constantly finding that M-f and M-b don't do what I want them to,
and I can't get them to behave how I want either. How about the
option of an emacs-like {forward,backward}-word, which jumps to a
different place depending on which direction you're heading, for
example?
> * Support for the LS_COLORS environment string, to colorize file names in
> the same contexts where the LIST_TYPES option presently appends various
> markers ('/' for directories, '@' for symlinks, etc.). Depends on the
> terminal having color capability, obviously.
>
> The only issue about this one is that it's borrowed from GNU copylefted
> source. I don't want to include it without an exemption from the GPL,
> and Greg doesn't want to pester the FSF about an exemption unless I'm
> certain to include it; so we're temporarily at an impasse. If several
> zsh users say they'd like to see this included, I'll tell Greg to go
> ahead and request the exemption.
I would /love/ to see this feature. I've been missing having that in
all the shells I've used.
Adam
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 6:51 Call for opinions on a couple of prospective zsh patches Bart Schaefer
1999-06-06 13:36 ` Adam Spiers
@ 1999-06-06 14:13 ` Peter Stephenson
1999-06-06 16:40 ` Bart Schaefer
1999-06-09 16:34 ` WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches) Bart Schaefer
1999-06-06 16:50 ` Call for opinions on a couple of prospective zsh patches Stefan Monnier
2 siblings, 2 replies; 13+ messages in thread
From: Peter Stephenson @ 1999-06-06 14:13 UTC (permalink / raw)
To: zsh-users
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]
"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 <pws@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 13:36 ` Adam Spiers
@ 1999-06-06 16:20 ` Bart Schaefer
0 siblings, 0 replies; 13+ messages in thread
From: Bart Schaefer @ 1999-06-06 16:20 UTC (permalink / raw)
To: zsh-users
On Jun 6, 2:36pm, Adam Spiers wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
} > features that could appear in zsh 3.0.6. I'm undecided whether to add
} > any or all of them. They are:
} >
} > * Completion using "dynamic abbreviations" after the manner of the emacs
} > dabbrev package. This includes adding a special `dabbrev-complete' ZLE
} > action, along the lines of expand-or-complete, complete-word, etc.
}
} Personally I find this feature so useful that I can't stand being
} without it, and still use that version with my patch hacked in to this
} day, which is unfortunate, because it's prevented me from regularly
} trying out the newer development versions.
}
} Which versions is zle -C (or similar) available in these days?
Peter has been doing interim unofficial patch releases about once a week
for some while now, because Zefram's net access has been intermittent.
The "zle -C" stuff merged with some other completion changes that Sven
Wischnowsky implemented, and all will appear in 3.1.6.
(You know you've been reading zsh-workers a long time when you can spell
Wischnowsky without looking it up.)
} > I find the effects of `dabbrev-complete' to be -very- similar to
} > setopt menu_complete
} > compctl -D -s '${=$(history -nr 1)}'
}
} Also, I don't like the idea of menu-completion behaviour, because I
} tend to keep a huge history (precisely for the reason that it makes a
} dabbrev-expand action so useful), so I'd end up with huge menus (or a
} "do you want a huge menu" prompt) most times I hit the key. Ugh.
I think you're confusing menu-completion with completion listings. In a
menu completion, repeatedly striking the completion key (e.g. TAB) cycles
through the list of possible matches; you still see only one at a time,
and you aren't prompted about it. Listing behavior (setopt auto_list and
list_ambiguous) means that if the word can't be completed, all possible
matches are displayed (or you get prompted if there are too many).
Greg's patches do not cause listing behavior, ever; it's a new builtin,
so it doesn't recognize the regular completion options. Hm, I'd probably
have to try to do something about that if I were going to include it.
} I'd say that if this next 3.1 release is coming soon then maybe don't
} bother.
The 3.1.6 release should not be very far apart from the 3.0.6 release,
barring unforseen circumstances.
Slightly off-topic:
} I'm constantly finding that M-f and M-b don't do what I want them to,
} and I can't get them to behave how I want either. How about the
} option of an emacs-like {forward,backward}-word, which jumps to a
} different place depending on which direction you're heading, for
} example?
I imagine this was either an oversight, or works the way it does because
Paul Falstad didn't like having two spaces left behind following a
forward-word backward-delete-word sequence. I've long been using
bindkey -s '^[f' '^[E^F'
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 14:13 ` Peter Stephenson
@ 1999-06-06 16:40 ` Bart Schaefer
1999-06-09 16:34 ` WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches) Bart Schaefer
1 sibling, 0 replies; 13+ messages in thread
From: Bart Schaefer @ 1999-06-06 16:40 UTC (permalink / raw)
To: zsh-users
On Jun 6, 4:13pm, Peter Stephenson wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} "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.
}
} 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).
Looking at it more closely, I see that Greg didn't supply backward motion,
only forward motion and both forward and backward deletion. It wouldn't
be difficult for me to add backward motion.
However, as you point out:
} ... forward-word puts the cursor *after* the non-word character ...
and so does backward-word; both assume that there is at least one non-word
character between words, which isNotTheCaseHere. So a simple change for
something like WORDCHARS would leave the cursor in the wrong place on
every motion.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 6:51 Call for opinions on a couple of prospective zsh patches Bart Schaefer
1999-06-06 13:36 ` Adam Spiers
1999-06-06 14:13 ` Peter Stephenson
@ 1999-06-06 16:50 ` Stefan Monnier
1999-06-06 17:13 ` Adam Spiers
2 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 1999-06-06 16:50 UTC (permalink / raw)
To: zsh-users
>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> * Completion using "dynamic abbreviations" after the manner of the emacs
[...]
> * Partial word motions in the face of mixed case, i.e. move the cursor to
[...]
> * Support for the LS_COLORS environment string, to colorize file names in
I think adding anything to 3.0 is a mistake. We should instead hurry to
get 3.2 out the door. 3.1.x has too many neat features that most people don't
get to use since RedHat and friends only come with 3.0.5.
Adding any of the three to 3.1 makes sense, but to 3.0 ?
I really wish the next 3.1.x were called 3.2.0.
Stefan
PS: GNU ls's LS_COLORS code is brain dead: if you want to include it at least
try to fix it so that its auto-detection of color capability is a bit less
pathetically optimistic (trying to colorize the output when TERM=dumb
is ...well... dumb!)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 16:50 ` Call for opinions on a couple of prospective zsh patches Stefan Monnier
@ 1999-06-06 17:13 ` Adam Spiers
1999-06-06 17:25 ` Bart Schaefer
0 siblings, 1 reply; 13+ messages in thread
From: Adam Spiers @ 1999-06-06 17:13 UTC (permalink / raw)
To: zsh-users
Stefan Monnier (monnier+lists/zsh/users/news/@tequila.cs.yale.edu) wrote:
> I think adding anything to 3.0 is a mistake. We should instead hurry to
> get 3.2 out the door. 3.1.x has too many neat features that most people don't
> get to use since RedHat and friends only come with 3.0.5.
>
> Adding any of the three to 3.1 makes sense, but to 3.0 ?
> I really wish the next 3.1.x were called 3.2.0.
I'm no zsh developer really so my opinion shouldn't count for much,
but I'm with Stefan here. 3.0.x is really quite old now and I know
that there is some really nice stuff in 3.1.x which I would rather see
released in stable form at the expense of maintaining 3.0.x. Then
again, it may be that there's still a while to go before 3.1.x
approaches stability? In which case, forget everything I said :-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 17:13 ` Adam Spiers
@ 1999-06-06 17:25 ` Bart Schaefer
1999-06-06 18:41 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Bart Schaefer @ 1999-06-06 17:25 UTC (permalink / raw)
To: zsh-users
On Jun 6, 6:13pm, Adam Spiers wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} 3.0.x is really quite old now and I know that there is some really nice
} stuff in 3.1.x which I would rather see released in stable form at the
} expense of maintaining 3.0.x.
We've got separate people maintaining the two releases now, so there's
little conflict in keeping both updated.
} Then again, it may be that there's still a while to go before 3.1.x
} approaches stability?
There's a lot of very new stuff in 3.1 now which hasn't had exposure except
to the developers list, so there probably is a while to go. One concern is
to get out a Y2K-fixed 3.0 to be included in various linux releases etc.
before 3.2 reaches fruition.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 17:25 ` Bart Schaefer
@ 1999-06-06 18:41 ` Stefan Monnier
1999-06-07 1:22 ` Bart Schaefer
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 1999-06-06 18:41 UTC (permalink / raw)
To: zsh-users
>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> We've got separate people maintaining the two releases now, so there's
> little conflict in keeping both updated.
I simply have the impression that there hasn't been (m)any complaints
about 3.0.x stability, so why keep hacking on it instead of getting 3.2
ready for wider distribution ?
The 3.0.x line should be restricted to bug-fixes. Just like 3.2.x will be.
> One concern is to get out a Y2K-fixed 3.0 to be included in various linux
> releases etc. before 3.2 reaches fruition.
I don't see in what way dabbrev, LS_COLORS and `mixed case partial word
motions' will help fix the Y2K bug.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Call for opinions on a couple of prospective zsh patches
1999-06-06 18:41 ` Stefan Monnier
@ 1999-06-07 1:22 ` Bart Schaefer
0 siblings, 0 replies; 13+ messages in thread
From: Bart Schaefer @ 1999-06-07 1:22 UTC (permalink / raw)
To: zsh-users
On Jun 6, 2:41pm, Stefan Monnier wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} I simply have the impression that there hasn't been (m)any complaints
} about 3.0.x stability, so why keep hacking on it instead of getting 3.2
} ready for wider distribution ?
If it were a matter of "instead" I'd agree with you. I'll let Peter speak
to 3.2 timeframes, if he has an opinion.
} The 3.0.x line should be restricted to bug-fixes. Just like 3.2.x will be.
So far, there are 42 new ChangeLog entries in 3.0.6. Of those, five (or
maybe six, see below) represent minor new features, all of which were first
introduced in 3.1.x. (Greg's changes are the most significant I've looked
at, which I why I'm asking about them.) The others are all bugfixes, many
of which also originated in 3.1.x.
Since somebody will ask, the five new features are:
* The `preexec' function, like `precmd' but executed just before
each command line is executed;
* `emulate -L ...' short for `emulate ...; setopt localoptions';
* Quoted strings may appear inside ${...}; e.g. ${(f)"$(typeset)"}
is equivalent to "${(@f)$(typeset)}";
* The a, c, and m glob qualifiers (access, inode change, and modify
time comparisons) now accept times in seconds;
* The HIST_REDUCE_BLANKS option was added, to cause history entries
not to store strings of consecutive IFS characters between words
(history searches also ignore most whitespace).
The PRINT_EIGHT_BIT option was also added, but I consider that a bugfix.
} > One concern is to get out a Y2K-fixed 3.0 to be included in various linux
} > releases etc. before 3.2 reaches fruition.
}
} I don't see in what way dabbrev, LS_COLORS and `mixed case partial word
} motions' will help fix the Y2K bug.
This is true; note I said "one concern." Another (which I should have
mentioned, but I was in a hurry earlier) is to reduce "culture shock" when
people upgrade to 3.1.6 or 3.2. For example, 3.1.6 will introduce a new
format for storing extended (timestamped) history entries in .zhistory.
Both 3.0.6 and 3.1.6 will be able to read both the old and new formats
(this is the maybe-sixth new feature) so that you can continue to switch
back and forth between development and stable releases if you want to;
but 3.0.6 still writes the old format.
The five changes above are all to increase compatibility between 3.1 and
3.0 configurations/scripts, though there will still be things you can do
in 3.1.6 that you simply can't do in 3.0.anything.
In any case, the point is that there is going to be a 3.0.6 release, and
the next 3.1 release won't be 3.2, so I don't want to arbitrarily exclude
anything that a significant number of zsh-users would find useful. (If
it impacted stability, that would be another matter, but none of Greg's
changes are that radical from a code standpoint). If general sentiment
is to hold such new features entirely for 3.2, then I have no objection;
it saves me some effort.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches)
1999-06-06 14:13 ` Peter Stephenson
1999-06-06 16:40 ` Bart Schaefer
@ 1999-06-09 16:34 ` Bart Schaefer
1999-06-10 0:51 ` Stefan Monnier
1999-06-10 8:15 ` WORDCHARS, etc Peter Stephenson
1 sibling, 2 replies; 13+ messages in thread
From: Bart Schaefer @ 1999-06-09 16:34 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches)
1999-06-09 16:34 ` WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches) Bart Schaefer
@ 1999-06-10 0:51 ` Stefan Monnier
1999-06-10 8:15 ` WORDCHARS, etc Peter Stephenson
1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 1999-06-10 0:51 UTC (permalink / raw)
To: zsh-users
>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> 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
Somewhat agreed (except I don't agree with the particular split).
In Emacs, this is solved by having
backward-word
and
backward-sexp
The <foo>-sexp manipulation commands would be great.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WORDCHARS, etc.
1999-06-09 16:34 ` WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches) Bart Schaefer
1999-06-10 0:51 ` Stefan Monnier
@ 1999-06-10 8:15 ` Peter Stephenson
1 sibling, 0 replies; 13+ messages in thread
From: Peter Stephenson @ 1999-06-10 8:15 UTC (permalink / raw)
To: zsh-users
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~1999-06-10 8:45 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-06 6:51 Call for opinions on a couple of prospective zsh patches Bart Schaefer
1999-06-06 13:36 ` Adam Spiers
1999-06-06 16:20 ` Bart Schaefer
1999-06-06 14:13 ` Peter Stephenson
1999-06-06 16:40 ` Bart Schaefer
1999-06-09 16:34 ` WORDCHARS (Re: Call for opinions on a couple of prospective zsh patches) Bart Schaefer
1999-06-10 0:51 ` Stefan Monnier
1999-06-10 8:15 ` WORDCHARS, etc Peter Stephenson
1999-06-06 16:50 ` Call for opinions on a couple of prospective zsh patches Stefan Monnier
1999-06-06 17:13 ` Adam Spiers
1999-06-06 17:25 ` Bart Schaefer
1999-06-06 18:41 ` Stefan Monnier
1999-06-07 1:22 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).