Re: Oh my God! They killed completion! YOU BASTARDS!

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On May 17,  1:58am, TGAPE! wrote:
} Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
}
} Andrew Main wrote:
} > 
} > Bart Schaefer wrote:
} >> Maybe a better approach would be to distribute an autoloadable script
} >> that, when run, would report the differences between the current zsh and
} >> a specified previous version (default the last major release).
} >
} > That's what Etc/NEWS is for.  It needs to be updated for 3.1.
} 
} Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be
} longer than many people wish to read before starting to use the new
} shell, as well as frequently being too terse [...] to be of much use
} anyway - they generally assume that the new program'll work the same as
} their old version, except for bug fixes, until they play with the new
} options.

This is exactly why I generally object so much when changes are made that
are not "backwards compatible."  A shell isn't like other applications --
if it doesn't start up properly because it can't parse your init files,
you may not even be able to log in; and if it does start, but behaves in
an unexpected way, it can waste many hours (and in extreme cases cause
loss of data) before sanity is restored.  This is not to say that any of
the 3.1.x changes have those effects, just to emphasize that care should
be taken when changing behaviors.

} When one of my friends upgrades zsh on his machine,
} there are dozens affected, many who aren't necessarily observant enough
} to realize 'Hey, a shell upgrade occurred, and zefram's done an annoying
} default option change on me on some option I'm completely unfamiliar
} with because I immediately dismissed it as a bad idea.'  I've heard
} there's someone at work who can do this to hundreds, and I've seen ISPs
} where they could potentially do it to thousands.

And it is often the case that when such an upgrade is done, the Etc/NEWS
and other auxiliary doc files aren't installed in any public place, so
those poor users can't read them even if they are so inclined.

I'm no longer the "zsh admin" for any significant group of people, but
I was for a while, and starting with about version 2.4 I always had to
dump a bunch of stuff in /etc/zshenv to be sure zsh continued to behave
the way everyone expected.  I'd bet admins assume that isn't necessary.

} I'd suggest rather than an emulate version, just a detect version, like
} vim has - when vim changes significantly, anyone who is used to the old
} version gets a comment about how their .vimrc file is for an older
} version, and would they please read about the changes.

This is why I suggested a script that would report differences; sysadmins
could set it up to run when the new version is first started up.  None of
zsh's startup files are suitable for version tagging because zsh has no
business rewriting them (except the .zhistory, which may be turned off),
so I can't advocate version detection as a built-in, but it could be done
in a sample /etc/zshenv or something.

} I personally wasn't affected by this one, as I happen to be paranoid -
} my .zlogin file sets all options the way I want them; if the default is
} what I want, I still set it that way.  Not everyone is as looney as
} myself, however.

I have conditionals for every version of zsh back to about 2.0 to figure
out which options are available and set them appropriately to keep things
working as consistently as possible.  Some of those branches haven't been
executed since 1994, but I figure if I take them out then I'll forget to
fix something the next time some option or other gets revised.

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