zsh-3.1.2-zefram3

zsh-3.1.2-zefram3

[Andrew Main]

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

Re: zsh-3.1.2-zefram3 on Solaris

[Andrei Tcherepanov]

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 )

Re: zsh-3.1.2-zefram3 on Solaris

[Andrew Main]

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

Re: zsh-3.1.2-zefram3

[Anthony Heading]

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

Re: zsh-3.1.2-zefram3

[Bart Schaefer]

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

Re: zsh-3.1.2-zefram3

[Peter Stephenson]

"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

Re: zsh-3.1.2-zefram3

[Anthony Heading]

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