* Oh my God! They killed completion! YOU BASTARDS! @ 1998-05-07 5:14 pacman 1998-05-07 8:58 ` Andrew Main 1998-05-07 18:08 ` Andrew R. Large 0 siblings, 2 replies; 12+ messages in thread From: pacman @ 1998-05-07 5:14 UTC (permalink / raw) To: zsh-workers Oh my God! They killed completion! YOU BASTARDS! I must object to the changes to completion behavior in zsh 3.1 as opposed to the previous versions. First, on the matter of LIST_AMBIGUOUS, I would suggest that if you're going to add a new option that dramatically alters some existing rules that people have been been using for a long time, at the very least you shouldn't turn it on by default! The principle of least astonishment has been grossly violated here. I have spent considerable time in the past fixing up my shell stratup files to get the thing to behave like I want it to. If I _wanted_ to use a new option, I'd like the chance to read about it first, and then turn it on if it sounds like a good idea. This particular option, I think, is not a good idea, and I don't appreciate having it forced upon me by a new default setting. Please, let's have a little backward compatibility. And it gets worse than that. In listing completions, zsh is now doing something really stupid. I type "echo $ZSH_<TAB>" (with autolist turned on) and what happens? 17:01 6 londo /home/pacman/src %echo $ZSH_ <--\ ZSH_NAME ZSH_VERSION | /---------------/ My cursor is sitting HERE! --/ WHAT THE HELL IS THAT? Who did this? Some anti-zsh person must have infiltrated the development group and sabotaged it. This behavior is wrong. It's SO wrong.. The vastness of your wrongness here astounds me. All the languages in the world do not have enough words to adequately describe the degree of wrongness exhibited by zsh 3.1 completion. If shells were rated on a scale of 1=right (zsh 3.0) to 10=wrong (COMMAND.COM), zsh's giant step backwards from 3.0 to 3.1 would earn it a rating equal to the number of atoms in the universe. This is like compiling a new version of vi, only to find out that it is an emacs clone. And this, unlike the first issue, can't even be fixed by toggling an option. The description of ALWAYS_LAST_PROMPT is brief and confusing (how can a completion key be given an argument? What does that mean? Is that a numeric prefix? Hello! Is anybody home? Completion bindings generally don't exist in vi command mode, and numeric prefixes generally don't exist in insert mode), but I tried turning it on and off, and it had no effect that I could see. Why do I consider this behavior wrong? Well, first, it's a shocking and virtually undocumented change in default behavior, which can't be good. Secondly, there is stuff on the screen below the prompt. Being down there, it looks like it should be part of the command line I'm editing, but it isn't. Please, undo this horrible thing. Put the prompt back at the bottom of the screen where it belongs. -- Alan Curry -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d? s++:-- a-- C++ UB+++L++++ P+ L+++>++++ E--- W-- N++ o K? w--- O? M-- V? PS+ PE+ Y+ PGP-(--) t* 5++ X+++ R- tv++ b-- DI- D++ G+++ !e h! r-->+++ y? ------END GEEK CODE BLOCK------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 5:14 Oh my God! They killed completion! YOU BASTARDS! pacman @ 1998-05-07 8:58 ` Andrew Main 1998-05-07 16:39 ` Bart Schaefer 1998-05-07 18:45 ` pacman 1998-05-07 18:08 ` Andrew R. Large 1 sibling, 2 replies; 12+ messages in thread From: Andrew Main @ 1998-05-07 8:58 UTC (permalink / raw) To: pacman; +Cc: zsh-workers pacman@cqc.com wrote: >I must object to the changes to completion behavior in zsh 3.1 as opposed to >the previous versions. First, on the matter of LIST_AMBIGUOUS, I would >suggest that if you're going to add a new option that dramatically alters >some existing rules that people have been been using for a long time, at the >very least you shouldn't turn it on by default! There was a policy decision made in 3.1.1 that, generally speaking, the clever interactive options should be enabled by default. It does change the default behaviour, but it doesn't affect scripts (where compatibility really matters), and the new behaviour is usually preferred. > If I _wanted_ to use a new option, I'd like the chance to read >about it first, and then turn it on if it sounds like a good idea. The Etc/NEWS file does list new options. These options being on by default isn't listed, but this is a beta version, and it is listed in the ChangeLog. >particular option, I think, is not a good idea, and I don't appreciate having >it forced upon me by a new default setting. Please, let's have a little >backward compatibility. Possibility for zsh-workers: should `emulate' have the capability to emulate earlier zsh versions? So `emulate zsh-2.3' would turn off LIST_AMBIGUOUS and so on. >17:01 6 londo /home/pacman/src %echo $ZSH_ <--\ >ZSH_NAME ZSH_VERSION | > /---------------/ >My cursor is sitting HERE! --/ WHAT THE HELL IS THAT? ALWAYS_LAST_PROMPT. One of my favourite features. It means that you don't waste screen space with old completion lists -- new lists visibly replace the old one -- and the command line doesn't jump around, so it's easier to keep your eyes on what you're editing. This has been available since 2.5. >This behavior is wrong. It's SO wrong.. The vastness of your wrongness here >astounds me. All the languages in the world do not have enough words to >adequately describe the degree of wrongness exhibited by zsh 3.1 completion. I'm glad to see I'm not the only person that gets this emotional about computer programs. But ALWAYS_LAST_PROMPT is right. It's SO right. So vastly right that having to use bash purees my brain when it puts the completion list in the wrong place. >This is like compiling a new version of vi, only to find out that it is an >emacs clone. Bad analogy. vi's popularity rests on having a simple and *complete* interface. zsh has a history of adding cool and unusual features. Surely you can't expect us to make no progress in this direction in two years? >And this, unlike the first issue, can't even be fixed by toggling an option. "unsetopt alwayslastprompt". >The description of ALWAYS_LAST_PROMPT is brief and confusing (how can a >completion key be given an argument? What does that mean? Is that a numeric >prefix? Yes. In vi mode you'd have to fiddle with the key bindings to do it. I doubt that anyone actually does this, though: just set the option the way you want it. >Secondly, there is stuff on the screen below the prompt. Being down there, it >looks like it should be part of the command line I'm editing, but it isn't. You'll get used to it, if you use it. I can understand how it might be confusing when unexpected. -zefram ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 8:58 ` Andrew Main @ 1998-05-07 16:39 ` Bart Schaefer 1998-05-07 16:47 ` Andrew Main 1998-05-07 18:45 ` pacman 1 sibling, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1998-05-07 16:39 UTC (permalink / raw) To: Andrew Main, pacman, zsh-workers On May 7, 9:58am, Andrew Main wrote: } Subject: Re: Oh my God! They killed completion! YOU BASTARDS! } } pacman@cqc.com wrote: } >I must object to the changes to completion behavior in zsh 3.1 as opposed to } >the previous versions. First, on the matter of LIST_AMBIGUOUS, I would } >suggest that if you're going to add a new option that dramatically alters } >some existing rules that people have been been using for a long time, at the } >very least you shouldn't turn it on by default! I'm surprised nobody has pointed out that LIST_AMBIGUOUS has been an option for several versions now. What changed was its default setting. } There was a policy decision made in 3.1.1 that, generally speaking, the } clever interactive options should be enabled by default. It does change } the default behaviour, but it doesn't affect scripts (where compatibility } really matters), and the new behaviour is usually preferred. I'm not sure if this is a problem for LIST_AMBIGUOUS (I haven't installed 3.1.4 yet) but we should be careful that a new default setting is not going to adversely affect other options that may be set in the user's .z* files. For example, if we were to make AUTO_MENU a default, people who normally set MENU_COMPLETE would be in for a nasty surprise. } > If I _wanted_ to use a new option, I'd like the chance to read } >about it first, and then turn it on if it sounds like a good idea. } } The Etc/NEWS file does list new options. Which doesn't help for either of LIST_AMBIGUOUS or ALWAYS_LAST_PROMPT, because they aren't new. } >particular option, I think, is not a good idea, and I don't appreciate } >having it forced upon me by a new default setting. Please, let's have } >a little backward compatibility. } } Possibility for zsh-workers: should `emulate' have the capability to } emulate earlier zsh versions? 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). Alternately/additionally, have a script that would search the PATH for older versions of zsh (`make install` usually leaves old versions behind as zsh-x.y.z), allow the user to pick one, and generate on stdout a list of setopt commands the user might want to add to his .zshrc, e.g., by comparing the output of "setopt" from the old version to the current one. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 16:39 ` Bart Schaefer @ 1998-05-07 16:47 ` Andrew Main 1998-05-17 1:58 ` TGAPE! 0 siblings, 1 reply; 12+ messages in thread From: Andrew Main @ 1998-05-07 16:47 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers 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. -zefram ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 16:47 ` Andrew Main @ 1998-05-17 1:58 ` TGAPE! 1998-05-17 9:19 ` Bart Schaefer 1998-05-18 5:12 ` Zoltan Hidvegi 0 siblings, 2 replies; 12+ messages in thread From: TGAPE! @ 1998-05-17 1:58 UTC (permalink / raw) To: Andrew Main; +Cc: schaefer, zsh-workers 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. Documentation's great. So, who in this group is a documentation fanatic? No one, I see. That would explain why the documentation is so friggin out of date. Of course, the fact that the documentation is actually spread out between so many files probably contributes to it; I usually find that at least the manpages are current, which is a good thing. The others - I've learned to mostly ignore them, they too rarely have the right information for the problems I look at them for. This is at least better than at work, where I find talking to the author is frequently the only way to go, as the documentation was last updated in '96, and the code last updated last month. (Ok, exaggeration - month and a half ago, and it was December '96.) 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 (this isn't a contradiction, rather a statement of human nature) 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 a good thing, especially on machines which have multiple users - when I upgrade zsh on my machine, *I* am the primary person affected. 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. 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. Anyone who doesn't have a version tag in their configuration file is obviously using an older version. At work, I control the upgrades for vim, and there are about half a dozen people who use it. So far, I've never had a complaint about unexpected changes due to an upgrade. 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 personally use the feature Alan castigated as the worst idea ever thought of, but then he'd probably be one of the first people to mention I have little sense. Still, I agree with him that it shouldn't be default. Just because it's useful doesn't mean that it should be set as a trap to the unwary; most people who start using zsh are used to other shells which don't do that. (Btw, yes, I would find it more convenient if my compctl lines didn't have to include every friggin completion. Course, not trusting you guys, I probably still wouldn't be lazy and remove the redundant ones.) And, Alan, the emacs call was highly out of line - if they made this change in emacs style, to use it, you'd have had to type Esc-xcomplete-word-and-move-the-cursor-to-the-line-the-previous-prompt, which of course can only be feasibly typed by pressing tab an inordinante number of times, to distinguish it from complete-line, complete-word-and-enter, complete-word-and-move-the-mouse-randomly, complete-word-and-move-the-cursor-to-the-top-of-the-screen, and other such blatherskite. If they ever do try something like this to zsh I will agree that they should be drawn, quartered, shot, flayed, salted, filleted, burned at the stake, and beheaded (but otherwise treated with respect, unlike Our Friend Bill). I do feel that, considering what the list of things to bind keys to, Kenny is in danger. Hopefully, this is a Christmas show... --\Grimm, tgape@bigfoot.com Ed|-----BEGIN GEEK CODE BLOCK----- A|Version: 3.1 lv|GS/CS/O/>AT PS+-->? PE++()>? Y+-->? PGP->- G++(-) t+--- s+:- c++++$ K in|N(++) b++(++++) d+$(-) 5 O- !tv-- !E---$>? ULIBS(VUCX)+$(++++$)>++++$ G|R(-)* V--$ a->970(?) w---($)>----!? W--()(-)>? P++-- C++$(---)(>?) >o ri|X-->? y+-*>++++** M-$>? D++--- DI++++>$ e++* h+* r--%*>+++ L+++>++++$ mm|------END GEEK CODE BLOCK------ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-17 1:58 ` TGAPE! @ 1998-05-17 9:19 ` Bart Schaefer 1998-05-18 5:12 ` Zoltan Hidvegi 1 sibling, 0 replies; 12+ messages in thread From: Bart Schaefer @ 1998-05-17 9:19 UTC (permalink / raw) To: TGAPE!, Andrew Main; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-17 1:58 ` TGAPE! 1998-05-17 9:19 ` Bart Schaefer @ 1998-05-18 5:12 ` Zoltan Hidvegi 1 sibling, 0 replies; 12+ messages in thread From: Zoltan Hidvegi @ 1998-05-18 5:12 UTC (permalink / raw) To: tgape; +Cc: Zsh hacking and development TGAPE! <tgape@cyberramp.net> wrote: > > That's what Etc/NEWS is for. It needs to be updated for 3.1. > > Documentation's great. So, who in this group is a documentation > fanatic? No one, I see. That would explain why the documentation is so > friggin out of date. Of course, the fact that the documentation is You can help if you have time. People develop zsh in their free time for fun, and it looks like most of them find more fun in coding than in documentation. The main documentation, the manual is kept up to date, and you can get a very nice printed documentation from the texinfo version. It's more than a hundred page long with nice indexes and table of contents. It's worth reading, even experienced developers can learn from it. Unfortunately it is too long and written in the usual Unix manpage style language which is sometimes hard to read for inexperienced users. > Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be ChangeLog is not for the users, it is a log for the developers. Etc/NEWS is updated for major releases, but it may lag behind the changes during the development. Note that 3.1 is beta, it is under development, and noone guarantees that it'll work as you expect. If you chose to use beta software, you should be prepared for surprises. The announcement on zsh-announce did describe the changed options. > person affected. 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. First it was not Zefram but me who changed this with the approval from most of the people reading zsh-workers at that time. And if a system administrator installs a beta software for dezens or maybe thousans of users, he should have a good reason and then he probably knows how to handle these issues. He can set up /etc/zshenv to set the option preferred by the users. The default options were changed to make the shell more usable without playing with options. Many users did not even know about these options since they never read the manual. Of course the choice of options is a matter of taste, but there seemd to be a consensus here on the new set. > people to mention I have little sense. Still, I agree with him that it > shouldn't be default. Just because it's useful doesn't mean that it > should be set as a trap to the unwary; most people who start using zsh > are used to other shells which don't do that. But most people start using zsh exactly because it does things that other shells don't. Actually ALWAYS_LAST_PROMPT was one of the main reasons I started using zsh. When I saw this behavior, I saw the light :-). Zoltan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 8:58 ` Andrew Main 1998-05-07 16:39 ` Bart Schaefer @ 1998-05-07 18:45 ` pacman 1998-05-08 8:59 ` Andrew Main 1 sibling, 1 reply; 12+ messages in thread From: pacman @ 1998-05-07 18:45 UTC (permalink / raw) To: zsh-workers Andrew Main wrote: > >pacman@cqc.com wrote: > >There was a policy decision made in 3.1.1 that, generally speaking, the >clever interactive options should be enabled by default. For new features, that might make sense. For things which are variations on an existing feature, I'm not so sure. > It does change >the default behaviour, but it doesn't affect scripts (where compatibility >really matters), and the new behaviour is usually preferred. It broke a script in my head, which says "Left little finger pushes tab. Eyes move to bottom of screen to find cursor". My brain-script has been working that way since zsh 2.5 or so, and before that, it worked that way with tcsh. > >The Etc/NEWS file does list new options. These options being on by >default isn't listed, but this is a beta version, and it is listed in >the ChangeLog. OK, now I have a roadmap for upgrade: read that new option list and then check their description, and turn them off if you're married to the old behavior. > >>17:01 6 londo /home/pacman/src %echo $ZSH_ <--\ >>ZSH_NAME ZSH_VERSION | >> /---------------/ >>My cursor is sitting HERE! --/ WHAT THE HELL IS THAT? > >ALWAYS_LAST_PROMPT. One of my favourite features. It means that you >don't waste screen space with old completion lists -- new lists visibly >replace the old one -- and the command line doesn't jump around, so >it's easier to keep your eyes on what you're editing. This has been >available since 2.5. You make it sound so nice, but I'm really used to knowing that everything after my prompt is part of the command I'm typing. Considering multi-line, ZLE, there really is no clear separator between what is part of the command line, and what is just some other stuff after it, except that you can't move the cursor down there. Even ^R and ^L treat the completion list as if it was part of the command line! Ugh! > >I'm glad to see I'm not the only person that gets this emotional about >computer programs. You should have seen me. I was pounding my desk and straining to keep from screaming. > >But ALWAYS_LAST_PROMPT is right. It's SO right. So vastly right that >having to use bash purees my brain when it puts the completion list in >the wrong place. That's funny, the first thing I thought when I saw it happen was "Oh no, this must be some crazy bash feature. They're cloning bash now." > >"unsetopt alwayslastprompt". What I tried was "setopt noalwayslastprompt" and it didn't seem to have an effect. Of course now, after I complain about it, it does. I should have saved the history from that test, because now I'll never know what was happening. OK, I'll revise my complaint: FAQ 4.3, which lists all the completion-related options, doesn't have alwayslastprompt. >You'll get used to it, if you use it. I can understand how it might be >confusing when unexpected. > Quite. More minor things I noticed while playing around: With 3.0, there is a default compctl for setopt itself. In 3.1, it seems to be gone. What do I have to do, pick apart the compctl example file and add lots of stuff to /etc/zshrc, just to make 3.1 catch up with 3.0's default completion awareness? With automenu on, echo $ZSH_<TAB><TAB> shows ZSH_NAME with a slash after it. Why's that? -- Alan Curry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 18:45 ` pacman @ 1998-05-08 8:59 ` Andrew Main 0 siblings, 0 replies; 12+ messages in thread From: Andrew Main @ 1998-05-08 8:59 UTC (permalink / raw) To: pacman; +Cc: zsh-workers pacman@cqc.com wrote: > Even ^R and ^L treat the completion list as if it was >part of the command line! Ugh! I was rather proud of that addition, actually. >With automenu on, echo $ZSH_<TAB><TAB> shows ZSH_NAME with a slash after it. >Why's that? That's AUTO_PARAM_SLASH. It adds a slash after a parameter name if the parameter's value happens to be the name of a directory. Not really appropriate with ZSH_NAME, but the slash will go away quite readily if you have AUTO_REMOVE_SLASH set. -zefram ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 5:14 Oh my God! They killed completion! YOU BASTARDS! pacman 1998-05-07 8:58 ` Andrew Main @ 1998-05-07 18:08 ` Andrew R. Large 1 sibling, 0 replies; 12+ messages in thread From: Andrew R. Large @ 1998-05-07 18:08 UTC (permalink / raw) To: zsh-workers pacman@cqc.com (07 May 1998 at 00:14 GMT as "pacman@cqc.com") said: > > [Passionate diatribe deleted] > Sorry to waste a little bandwith for this, but I wanted to give the first few respondents to this message some major kudos. To me, the original message sounded a bit like an attempt to start a flame war. Rather than responding in kind or castigating the fellow for poor manners, you all responded very professionally. Rare to see these days in Internet forums, and highly appreciated. [And yes, for the record, I like the feature Mr. pacman was complaining about] -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=- Andrew Large | Sun Microsystems, Inc. andrew.large@eng.sun.com | 901 San Antonio Road (650) 786-6503 [office] | MS MPK18-209 (650) 786-4101 [fax] | Palo Alto, CA 94303-4900 -=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! @ 1998-05-07 9:30 Sven Wischnowsky 1998-05-07 9:59 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Sven Wischnowsky @ 1998-05-07 9:30 UTC (permalink / raw) To: zsh-workers Andrew Main wrote: > > pacman@cqc.com wrote: > > > > ... [ about LIST_AMBIGUOUS being set by default...] > > > ... > This one confused me a bit, too, on my first TAB after the change since I don't use it and missed the corresponding messages... > > Possibility for zsh-workers: should `emulate' have the capability to > emulate earlier zsh versions? So `emulate zsh-2.3' would turn off > LIST_AMBIGUOUS and so on. > Hm. That may result in pretty complicated code sometimes, if this is not restricted to option settings. (Not that the current code is simple...;-) > >17:01 6 londo /home/pacman/src %echo $ZSH_ <--\ > >ZSH_NAME ZSH_VERSION | > > /---------------/ > >My cursor is sitting HERE! --/ WHAT THE HELL IS THAT? > > ALWAYS_LAST_PROMPT. One of my favourite features. It means that you > don't waste screen space with old completion lists -- new lists visibly > replace the old one -- and the command line doesn't jump around, so > it's easier to keep your eyes on what you're editing. This has been > available since 2.5. > > >This behavior is wrong. It's SO wrong.. The vastness of your wrongness here > >astounds me. All the languages in the world do not have enough words to > >adequately describe the degree of wrongness exhibited by zsh 3.1 completion. > > I'm glad to see I'm not the only person that gets this emotional about > computer programs. > > But ALWAYS_LAST_PROMPT is right. It's SO right. So vastly right that > having to use bash purees my brain when it puts the completion list in > the wrong place. > Interesting... for some of the things I implemented, I always wondered if people use it or even like it. ALWAYS_LAST_PROMPT was/is one of them. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Oh my God! They killed completion! YOU BASTARDS! 1998-05-07 9:30 Sven Wischnowsky @ 1998-05-07 9:59 ` Peter Stephenson 0 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 1998-05-07 9:59 UTC (permalink / raw) To: Zsh hackers list Sven Wischnowsky wrote: > Andrew Main wrote: > > > Possibility for zsh-workers: should `emulate' have the capability to > > emulate earlier zsh versions? So `emulate zsh-2.3' would turn off > > LIST_AMBIGUOUS and so on. > > > > Hm. That may result in pretty complicated code sometimes, if this is > not restricted to option settings. (Not that the current code is simple...;-) I'm afraid that's proably a fatal flaw with this, nice as it would be. If you have an emulate zsh-X, people are going to assume it does what its name suggest, rather than just change the options. Probably a clear list of changes in default options, maybe in the documentation as well as the news file so that it's available to users on most right-thinking systems, would be enough --- people just want to set them once in their .zshrc. Then we can avoid *too* many messages demonstrating passionate attachment to options... -- Peter Stephenson <pws@ifh.de> Tel: +39 50 844536 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-05-18 5:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-05-07 5:14 Oh my God! They killed completion! YOU BASTARDS! pacman 1998-05-07 8:58 ` Andrew Main 1998-05-07 16:39 ` Bart Schaefer 1998-05-07 16:47 ` Andrew Main 1998-05-17 1:58 ` TGAPE! 1998-05-17 9:19 ` Bart Schaefer 1998-05-18 5:12 ` Zoltan Hidvegi 1998-05-07 18:45 ` pacman 1998-05-08 8:59 ` Andrew Main 1998-05-07 18:08 ` Andrew R. Large 1998-05-07 9:30 Sven Wischnowsky 1998-05-07 9:59 ` Peter Stephenson
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).