* zsh-3.1.2-zefram3
@ 1998-01-12 11:27 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
0 siblings, 2 replies; 7+ messages in thread
From: Andrew Main @ 1998-01-12 11:27 UTC (permalink / raw)
To: zsh-workers
-----BEGIN PGP SIGNED MESSAGE-----
I've put together an unofficial release, version 3.1.2-zefram3. I'm not
up to doing a full release like Zoltan's -- his scripts in the top-level
Makefile don't suit my setup -- so, as was previously my custom with
unofficial releases, the only generated files in the tar are the
autoconf ones. You'd better have yodl.
Sizes:
117257 zsh-3.1.2-3.1.2-zefram3.diff.gz
669945 zsh-3.1.2-zefram3.tar.gz
MD5 checksums:
03be8fa383b7137f6c91963dbb00b541 zsh-3.1.2-3.1.2-zefram3.diff.gz
028b7c4e6fb9d9866e5ab44f23d0454d zsh-3.1.2-zefram3.tar.gz
As I'm on a relatively slow link here, that isn't intended to support
an ftp server, someone else will have to host this release. Offers of
ftp space would be appreciated. Until these files are ftpable, I am
prepared to send copies to developers by email.
A complete list of patches considered for this release is included below.
I'd particularly like to discuss the recent ZLE-related feature patches:
y 3492 pws compctl -/ for directory completion like -f
I like this a lot. I've really missed this capability in the
past, and the way it is done here is impressively neat. I also
updated the compctl-examples script to use -/ where appropriate,
which was quite a lot of places.
y 3498 pws compctl -W to complete under a directory
I suspect that this could be mostly achieved by -K functions.
However, it doesn't seem to be possible to precisely duplicate
the directory behaviour (-/), and this is reasonably neat.
N 3503 wischnow lots of nifty completion options
This I did not include. AUTO_GLOB_COMPLETE really has very
little to do with GLOB_COMPLETE -- all it does is complete from
the beginning of the word as well as the end. This is the sort
of thing that multicomp is for. COMPLETE_FOLD_CASE I would
have used had it been separate from the rest of the patch; it
does something useful that can't easily be done in user space.
The other compctl options (-. and -:) I do not like. They seem
to require an awful lot of code for something that, again,
should really be part of a completion function.
N 3554 ajrh allow vared to succeed on EOF
This can be done by temporarily rebinding ^D to accept-line, or
to a user-defined widget that conditionally calls accept-line.
(See Functions/zed for an example of how to temporarily change
bindings.) Also, while I agree that vared -c is not much
use, removing the option entirely will cause problems with
some scripts. Changing the default EOF behavior would cause
similar problems. While I would like the whole area of EOF
handling in ZLE to be re-examined, this patch does not do a
proper job of that.
N 3581 pws keyboard macros for ZLE
The functionality is good, but this should be done by *calling*
the input function, not by modifying it. Once input is done
via widgets, this will be implementable in user space.
y 3636 pws compctl -y and -Y
compctl -y is good. It does something that's been on my wish list
for a long time. Considering the way variables and functions
can both be specified with -y, maybe this should be extended to
-K for consistency. compctl -Y is pretty useful and neat, but
I include it with a reservation: perhaps it would be better to
have the explanation *always* be expanded. It wouldn't affect
any scripts, and we could use $_ instead of that icky %n thing.
Patch list:
y 2999 zefram RM_STAR_WAIT
y 3004 zefram emulate sh's default prompt
y 3050 zefram HIST_NO_FUNCTIONS
y 3052 zefram NO_PROMPT_PERCENT
N 3196 pws stty settings and background jobs [superseded by 3297]
y 3239 zefram prompt formatting
y 3240 zefram always build rlimits module
y 3241 zefram have static struct builtin objects in modules
y 3242 zefram makepro.awk handles all types of declaration
y 3243 zefram move global object declarations into source files
y 3244 zefram move documentation for bindkey et al into zshmodules(1)
y 3246 hzoli filter out garbage when importing environment variables
y 3247 hzoli AUTO_PARAM_KEYS bugfix
y 3249 pws end-of-pattern markers in globbing
y 3250 zefram paramsubst() fix for `set "$@"'
y 3251 pws removed memory leak in disown
y 3252 zefram automatic Makefile and header generation for module building
N 3253 suzuki stty settings and background jobs [superseded by 3297]
N 3257 suzuki stty settings and background jobs [superseded by 3297]
N 3258 hzoli stty settings and background jobs [superseded by 3297]
y 3260 gcw crash bug fix in ZLE refresh code
N 3261 pws 3.0 version of patch 3249 [3.0]
N 3263 suzuki stty settings and background jobs [superseded by 3297]
N 3264 hzoli stty settings and background jobs [superseded by 3297]
y 3285 pws in `*(-M)' the (-) should affect interpretation of (M)
y 3293 hzoli keep original environment around when initialising environment
y 3297 hzoli stty settings and background jobs
y 3301 pws fixing a couple of memory leaks
y 3302 suzuki set STAT_NOSTTY if a job is ever backgrounded
y 3308 pws avoid unwanted space addition in menu completion
y 3318 pws PRINT_EIGHT_BIT
y 3353 zefram ZLE suffix mechanism rewrite
y 3360 pws Prefer -lcurses to -ltermcap on HP-UX 10.*
y 3368 hzoli restrict use of leaf optimisation in recursive globs
y 3369 kunihiro rlimits.awk handles GNU-style <resourcebits.h>
N 3380 hzoli RC_EXPAND_PARAM general weirdness fix [superseded by 3403]
N 3381 hzoli `wrong character in hungetc()' fix [superseded by 3383]
y 3383 hzoli `wrong character in hungetc()' fix, fixed
y 3403 hzoli RC_EXPAND_PARAM, braces, and other widgets, consistentified
y 3417 pws documentation for 3403 (markup not quite right)
N 3418 pws print explanation iff there *are* matches [superseded by 3423]
y 3423 hzoli print explanation iff there are !=1 matches
y 3424 pws documentation for 3423
y 3438 pws completion in braces (clashes with 3353)
N 3441 harres zgetcwd() fix for automounted directories [redundant]
N 3446 pws makepro.sed fix for HP-UX [redundant with 3242]
N 3456 hzoli 3.0.4: avoid double scan in zgetcwd() [3.0.4]
N 3478 mrb zrealloc() performs the same checks as zalloc() [in 3522]
y 3484 schaefer c2z updates
y 3492 pws compctl -/ for directory completion like -f
y 3493 pws typo fix in documentation of 3492
y 3495 pws compctl display fix for 3492
N 3496 pws duplicate of 3495 [duplicate]
y 3498 pws compctl -W to complete under a directory
y 3502 pws typo fixes in new compctl options
N 3503 wischnow lots of nifty completion options [can be done in user space]
N 3507 wischnow #if 0 removal for 3503 [not using 3503]
y 3511 schaefer ZLE refresh bugfix
y 3513 pws fix for globbing [[ fofo == (fo#)# ]], etc.
y 3514 pws more glob fixes based on 3513
y 3515 pws yet more glob closure fixes
y 3522 hzoli 3478; rlimits.awk portability; some parameter fiddling
y 3525 pws cunning performance improvement for glob closures
y 3526 pws $(r)
y 3531 pws history suppression improvement
N 3547 pws RC_EXPAND_PARAM fix for empty arrays [superseded by 3548]
y 3548 hzoli better RC_EXPAND_PARAM fix for empty arrays
y 3549 pws better documentation of history expansion modifiers
N 3554 ajrh allow vared to succeed on EOF [can be done with widgets]
N 3558 wischnow fix for duplicating struct autofn [done a better way]
N 3565 wischnow fixes to 3503 [not using 3503]
N 3581 pws keyboard macros for ZLE [should be done more cleanly]
N 3582 pws fixes to 3581 [not using 3581]
N 3586 AIF go interactive if sourcing a tty [awkward behaviour]
N 3590 pws getopts fix [causes other buggy behaviour]
y 3598 pws New version of helpfiles script
N 3621 pws compctl -Y to display non-default list [superseded by 3636]
y 3625 eggink ZLE startup shuffle to avoid problems with vared and subshells
N 3626 pws compctl -Y with scalars [superseded by 3636]
y 3636 pws compctl -y and -Y
N 3638 schizo import $HISTCHARS [undesirable behaviour]
N 3644 wischnow duplicate of patch 3558 [duplicate]
N 3649 schaefer 3.0.5: do not adjust window size in zsh -c [3.0.5]
y u1068 pws preexec shell function
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: ascii
iQEVAwUBNLkoLZmk9GeOHh7BAQFInQf9FDsiKIqNsuGsevrgkHxNwYoDItqcubtO
3cAgO4BNt89bOTTEoBP/1PSYHQdSxr1HPuNwhgljHLerAKp3yvEU10LKTQU/JhCu
fwiqzdACIGLbzuFCfba9rUBpyBqjSgMJ3gHBBh6EsjwLEFD2PIk1SSsK4InkE0Ll
ieSTDOqNNKIioi6X+r4GBBwPxBXRCTC5tH0ZLcPZBjdD4Ra5Uz2tJKrsieGI8vah
Z7UOKQUkM0lf3puejUkGy5Ib8Q/kEFtuh2g5HFRaIT3yFwDtiAGyyoFo8frByPGX
u4ntlc7xcrEotPLrUwSrEcGkS1ru5zaqM5G/Hj3rDhI2zkkVMzFSgQ==
=TzVC
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3 on Solaris
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
@ 1998-01-13 9:29 ` Andrei Tcherepanov
1998-01-13 11:46 ` Andrew Main
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
1 sibling, 1 reply; 7+ messages in thread
From: Andrei Tcherepanov @ 1998-01-13 9:29 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
Hi!
Does somebody built on Solaris 2.5.1 ???
configure pass well, but on make it will explose in scripts.
It looks like scripts not work with solaris /bin/sh --
it have another translation for ' and " in echos
--
Thanks,
Andrei ( tandr@ptc.com )
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3 on Solaris
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
@ 1998-01-13 11:46 ` Andrew Main
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Main @ 1998-01-13 11:46 UTC (permalink / raw)
To: Andrei Tcherepanov; +Cc: zefram, zsh-workers
Andrei Tcherepanov wrote:
>Does somebody built on Solaris 2.5.1 ???
>
>configure pass well, but on make it will explose in scripts.
>
>It looks like scripts not work with solaris /bin/sh --
>it have another translation for ' and " in echos
Where does it fall over? Can you determine what part of which script
is at fault?
-zefram
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
@ 1998-01-18 15:14 ` Anthony Heading
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1 sibling, 1 reply; 7+ messages in thread
From: Anthony Heading @ 1998-01-18 15:14 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
On Mon, Jan 12, 1998 at 11:27:05AM +0000, Andrew Main wrote:
> I'd particularly like to discuss the recent ZLE-related feature patches:
> [...]
> N 3554 ajrh allow vared to succeed on EOF
> This can be done by temporarily rebinding ^D to accept-line, or
> to a user-defined widget that conditionally calls accept-line.
> (See Functions/zed for an example of how to temporarily change
> bindings.) Also, while I agree that vared -c is not much
> use, removing the option entirely will cause problems with
> some scripts. Changing the default EOF behavior would cause
> similar problems. While I would like the whole area of EOF
> handling in ZLE to be re-examined, this patch does not do a
> proper job of that.
Hmmm. I'm not sure I understand quite what this means in practice.
Can we break it down?
PREMISE:
I would aver that the EOF char acting as accept-line is a natural
default (viz my original desire to emulate the RCS check-in input).
PRIMARY HANDLING OF EOF:
In zleread()
- if (!ll && isfirstln && c == eofchar) {
+ if (c == eofchar && cs == ll && cs == findbol()) {
eofsent = 1;
break;
}
I think that this is an improvement. I think the condition has been
changed at least once already in the past year, but nobody discussed
it and nobody complained, so preservation of the status-quo may have
been demonstrated de-facto not to be an overriding imperative.
Does anyone find this problematic? It's not difficult to make it
conditional on a vared flag, but Occam's razor advises not playing
silly buggers unless you need to.
VARED HANDLING OF -c:
Perhaps Zefram missed the fact that the patch retained the -c flag as
a null op? The balance as always is cost (incompatibility) against
benefit (here simplicity). I still suspect that the incompatibilty
is minimal: that no-one relies on that error condition in scripts.
But others may know better. Not important - it was just a cleanup.
VARED HANDLING OF EOF:
If you like, we could swap the sense of the -e flag and keep the
current behaviour as the default.
RE-EXAMINATION OF WHOLE OF ZLE EOF HANDLING:
I'd agree completely that this patch doesn't make a proper job of
anything like that. I'm not sure what all the issues are. It was
simply intended as a small step in the right direction
USE OF ZLE WIDGETS:
This is probably the point where I become unhinged. At least in the
environment where I work, flexibility in user-space configuration is
absolutely no substitute for a satisfactory default. And in the area
of multi-line zsh editing, zsh has a little tweaking still to do
before that default is reasonable.
Nu chto zh. Zefram: I think the only necessarily incompatible change
is the tweak to zleread(). Is that objectionable? All the others
can be reworked to preserve the current behaviour as default, if that
what you think is appropriate. If the problem is more that you don't
want to see eof handling touched until it's radically overhauled, I
think you'll need to clarify what needs done.
Anthony
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
@ 1998-01-18 17:38 ` Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
0 siblings, 2 replies; 7+ messages in thread
From: Bart Schaefer @ 1998-01-18 17:38 UTC (permalink / raw)
To: Anthony Heading, Andrew Main, zsh-workers
On Jan 18, 3:14pm, Anthony Heading wrote:
} Subject: Re: zsh-3.1.2-zefram3
}
} On Mon, Jan 12, 1998 at 11:27:05AM +0000, Andrew Main wrote:
} > I'd particularly like to discuss the recent ZLE-related feature patches:
} > [...]
} > N 3554 ajrh allow vared to succeed on EOF
} > This can be done by temporarily rebinding ^D to accept-line, or
} > to a user-defined widget that conditionally calls accept-line.
This is true, but seems clumsy especially because the EOF char is normally
overloaded as delete-char-or-list. You'd be forced to write a user-defined
widget that implemented `delete-char-or-list-or-eof' to make it work right.
On the other hand, I don't believe that vared *should* behave the way that
typing text into `cat` would. Vared is not a streaming editor; I expect
it to behave like an editor that controls my terminal, not like a process
blindly reading from standard input.
} PREMISE:
} I would aver that the EOF char acting as accept-line is a natural
} default (viz my original desire to emulate the RCS check-in input).
I would aver that there shouldn't *be* any recognized EOF char in vared,
just as there is no EOF in vi or emacs. That is, as best I can tell, the
current behavior.
} PRIMARY HANDLING OF EOF:
} In zleread()
}
} - if (!ll && isfirstln && c == eofchar) {
} + if (c == eofchar && cs == ll && cs == findbol()) {
} eofsent = 1;
} break;
} }
}
} I think that this is an improvement.
How exactly does this change the behavior, again? EOF on any empty line
is EOF, even in a multiline edit? Yes, I object to that. I want EOF to
be EOF when typed on an empty line at a PS1 prompt, and nowhere else.
} I think the condition has been
} changed at least once already in the past year, but nobody discussed
} it and nobody complained, so preservation of the status-quo may have
} been demonstrated de-facto not to be an overriding imperative.
The condition changed from 3.0.2 to 3.0.3, adding the "&& isfirstln".
That was sometime before 27 June 1997. I don't know exactly what that
accomplished.
} VARED HANDLING OF -c:
}
} Perhaps Zefram missed the fact that the patch retained the -c flag as
} a null op? The balance as always is cost (incompatibility) against
} benefit (here simplicity). I still suspect that the incompatibilty
} is minimal: that no-one relies on that error condition in scripts.
Scripts are not the only case to consider; I dislike having my interactive
habits disrupted, too. In this case, this wouldn't bother *me*, but ....
} VARED HANDLING OF EOF:
}
} If you like, we could swap the sense of the -e flag and keep the
} current behaviour as the default.
That would be preferable.
} USE OF ZLE WIDGETS:
}
} This is probably the point where I become unhinged. At least in the
} environment where I work, flexibility in user-space configuration is
} absolutely no substitute for a satisfactory default.
I agree completely.
} Nu chto zh.
What?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
@ 1998-01-19 8:58 ` Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
1 sibling, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 1998-01-19 8:58 UTC (permalink / raw)
To: Zsh hackers list
"Bart Schaefer" wrote:
> On Jan 18, 3:14pm, Anthony Heading wrote:
> } In zleread()
> }
> } - if (!ll && isfirstln && c == eofchar) {
> } + if (c == eofchar && cs == ll && cs == findbol()) {
> } eofsent = 1;
> } break;
> } }
> }
>
> The condition changed from 3.0.2 to 3.0.3, adding the "&& isfirstln".
> That was sometime before 27 June 1997. I don't know exactly what that
> accomplished.
I think it was I (all right, me) that changed it, so that if you type
\<RETURN> then typing a ^D acted as list-choices instead of eof. This
seemed logical since lexically you are in the middle of a line.
> } This is probably the point where I become unhinged. At least in the
> } environment where I work, flexibility in user-space configuration is
> } absolutely no substitute for a satisfactory default.
>
> I agree completely.
Actually, if we have a mission statement ("...proactively integrate
synergetic industry metaphors into a dynamic system-invariant
state-of-the-art user interface..." ???), I vote for inclusion of the
phrase "flexibility in user-space configuration is absolutely no
substitute for a satisfactory default" (suitably disguised, of course).
> } Nu chto zh.
>
> What?
Hmm, I don't think that one came out of the mission statement
generator.
--
Peter Stephenson <pws@ifh.de> Tel: +39 50 911239
WWW: http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
@ 1998-01-21 18:37 ` Anthony Heading
1 sibling, 0 replies; 7+ messages in thread
From: Anthony Heading @ 1998-01-21 18:37 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
Bart wrote:
> This is true, but seems clumsy especially because the EOF char is normally
> overloaded as delete-char-or-list. You'd be forced to write a user-defined
> widget that implemented `delete-char-or-list-or-eof' to make it work right.
Indeed.
> On the other hand, I don't believe that vared *should* behave the way that
> typing text into `cat` would. Vared is not a streaming editor; I expect
> it to behave like an editor that controls my terminal, not like a process
> blindly reading from standard input.
OK. I suppose I was thinking that vared could easily be a streaming editor,
and read standard input slightly less blindly.
> How exactly does this change the behavior, again? EOF on any empty line
> is EOF, even in a multiline edit? Yes, I object to that. I want EOF to
> be EOF when typed on an empty line at a PS1 prompt, and nowhere else.
Fair. But I want EOF to be EOF also in my vared-based `cat' emulator.
So at most, then, this should be an option for vared, and not a default.
I shall revamp my patch to be less intrusive, and not change any of the
current behaviour.
Cheers
A
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1998-01-21 18:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
1998-01-13 11:46 ` Andrew Main
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
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).