yet another undesired 3.1.5-pws-15 change

yet another undesired 3.1.5-pws-15 change

[Timothy J Luoma]

3.1.5-pws-15

#cd $la[tab] gives me

# cd $lapps[spacehere][cursor here]


3.1.4

#cd $la[tab] gives me
#cd $lapps/[cursor here]


how can I get the 3.1.4 behavior back?


TjL

ps -- there seem to be a LOT of these types of changes in 3.1.5.... I wish  
there were more consideration given to keeping things consistent for those  
who upgrade... changing the way things behave and making the user reconfigure  
everything is not a good thing... I've gotten used to the way ZSH works, and  
then it goes and changes.  My only real option then is to stick with an  
older version and lose out on the new features which aren't available.  This  
is the wrong way to proceed.  I think PINE has the right idea: add options,  
but make the user select to use them (they tried to change a lot in PINE4 and  
the users revolted, and they soon put back in the previous functionality).

Since I haven't been on the workers list, maybe I have missed the rationale  
here: What is the reason behind changing these behaviors?

Re: yet another undesired 3.1.5-pws-15 change

[Wayne Davison]

Timothy J Luoma writes:
> ps -- there seem to be a LOT of these types of changes in
> 3.1.5.... I wish there were more consideration given to keeping
> things consistent for those who upgrade...

It sounds like you aren't aware that all the 3.1.x releases are in
development.  The release code-base is currently 3.0.x, with 3.0.6
just about to be released.  There are bound to be inconsistencies
(that certainly need to be found and fixed) in the most recent
development code, so if you're expecting a nice, safe upgrade (rather
than helping out with the development), you should be using the
3.0.x source.

..wayne..

Re: yet another undesired 3.1.5-pws-15 change

[Timothy J Luoma]

Replying to message of Wed, 28 Apr 1999 11:13:33 -0700
	from Wayne Davison <wayne@clari.net>
	regarding ``Re: yet another undesired 3.1.5-pws-15 change ''
	
> Timothy J Luoma writes:
> > ps -- there seem to be a LOT of these types of changes in
> > 3.1.5.... I wish there were more consideration given to keeping
> > things consistent for those who upgrade...
>
> It sounds like you aren't aware that all the 3.1.x releases are in
> development.  The release code-base is currently 3.0.x, with 3.0.6
> just about to be released.  There are bound to be inconsistencies
> (that certainly need to be found and fixed) in the most recent
> development code, so if you're expecting a nice, safe upgrade (rather
> than helping out with the development), you should be using the
> 3.0.x source.

I understand that they are "in development" but are you suggesting that I  
wait until the release has been "finalized" to note "hey, this upgrade breaks  
stuff"?

When the "final" release comes about, it should be (imo) ready to drop in as  
a replacement, meaning that users will _not_ notice any changees unless they  
want to take advantage of them.

The "default" behavior should not change between releases.  For that to  
happen, there need to be people who are not only checking how new features  
work, but how old features work.

Waiting until development is "finished" seems foolish.... after all, are the  
ZSH folks going to want to go back in and start patching things again?  Are  
sysadmins going to be happy when they install the newest "final" version only  
to find out that it isn't backward-compatible, and they either have to a)  
have all their users change the way they work or b) reinstall an older  
version?

Maybe I have some assumptions which are not shared by all:

Don't we want people to use the newest version of zsh (when ready, not beta  
version), assuming it will have fewer bugs?

If NO, why not?

If YES, then does it not also follow that the latest zsh ought to be  
backwards-compatible?

	If NO, then how do "we" expect sysadmins to respond (and users for
	that matter)?  Do we expect them to tweak their various files
	because things have changed?
	
I can tell you that I'm not as apt to install the latest version if it is  
going to break ENV settings, functions, etc.

TjL
	

Re: yet another undesired 3.1.5-pws-15 change

[Sven Wischnowsky]

Timothy J Luoma wrote:

> 3.1.5-pws-15
> 
> #cd $la[tab] gives me
> 
> # cd $lapps[spacehere][cursor here]
> 
> how can I get the 3.1.4 behavior back?

By applying the patch below.

> ps -- there seem to be a LOT of these types of changes in 3.1.5....

Please name them, because...

> I wish  
> there were more consideration given to keeping things consistent for those  
> who upgrade... changing the way things behave and making the user reconfigure  
> everything is not a good thing...

...of course, we (w.r.t. the completion code: I) tried to keep the old
behavior, but there were a lot of changes in the code needed for the
new features (and there are many of them) and so I didn't manage to do
so in some cases.

Again: if you find things that behave differently now, and if the
change isn't a good thing, please let us know and I'll attempt to fix
it.


As for your other message: I need some more help here since I can't
reproduce it. Can you complete the names that don't appear in the
list? By giving an unambiguous prefix? Only with menucompletion? This
is NextStep (right?): did you get any compiler warnings in
Zle/zle_tricky.c? (Weird question, but I have no idea how what you
described can happen...)


The patch: it's do_single() again, failing to build the expanded path
for the parameter just completed.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Apr 13 10:32:15 1999
+++ Src/Zle/zle_tricky.c	Fri Apr 23 12:45:52 1999
@@ -6970,10 +6976,20 @@
 		t = 1;
 	    else {
 		/* Build the path name. */
-		p = (char *) zhalloc(strlen(prpre) + strlen(str) +
-				 strlen(psuf) + 3);
-		sprintf(p, "%s%s%s", (prpre && *prpre) ? prpre : "./", str, psuf);
+		if (m->ripre && !*psuf) {
+		    int ne = noerrs;
 
+		    p = (char *) zhalloc(strlen(m->ripre) + strlen(str) + 1);
+		    sprintf(p, "%s%s", m->ripre, str);
+		    noerrs = 1;
+		    parsestr(p);
+		    singsub(&p);
+		    noerrs = ne;
+		} else {
+		    p = (char *) zhalloc(strlen(prpre) + strlen(str) +
+				 strlen(psuf) + 3);
+		    sprintf(p, "%s%s%s", (prpre && *prpre) ? prpre : "./", str, psuf);
+		}
 		/* And do the stat. */
 		t = (!(sr = ztat(p, &buf, 0)) && S_ISDIR(buf.st_mode));
 	    }

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: yet another undesired 3.1.5-pws-15 change

[Timothy J Luoma]

Replying to message of Fri, 23 Apr 1999 12:59:46 +0200 (MET DST)
	from Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
	regarding ``Re: yet another undesired 3.1.5-pws-15 change''
	
> > ps -- there seem to be a LOT of these types of changes in 3.1.5....
>
> Please name them, because...

OK, I will make sure to mention them.

Earlier OLDPWD didn't behave the same way (it seems to now though)

There's still a problem with my PROMPT:

PROMPT='
---------------------------------------- %t/%T  
----------------------------------------
%S[OLDPWD: $OLDPWD]
   [PWD: %~]%s
%B%n$LOCAL_HOST%b $REMOTE_HOST
'

it produces an extra blank line at the end (unlike 3.1.4)


> > I wish there were more consideration given to keeping things
> > consistent for those who upgrade... changing the way things
> > behave and making the user reconfigure everything is not a good
> > thing...
>
> ...of course, we (w.r.t. the completion code: I) tried to keep the old
> behavior, but there were a lot of changes in the code needed for the
> new features (and there are many of them) and so I didn't manage to do
> so in some cases.

It was my misunderstanding then.  From some offlist replies I got to earlier  
comments, it sounded like "Things change, get over it."  I realize now that  
I should have guessed they were not the voice of authority.



> As for your other message: I need some more help here since I can't
> reproduce it. Can you complete the names that don't appear in the
> list? By giving an unambiguous prefix? Only with menucompletion? This
> is NextStep (right?): did you get any compiler warnings in
> Zle/zle_tricky.c? (Weird question, but I have no idea how what you
> described can happen...)

I don't remember any warnings... well, there were warnings, but I don't  
remember what they were.

I cannot solve it by giving unambiguous filenames:

# ls /
CDROM/              Users/              mach_kernel
LocalApps@          bin/                mach_kernel.OS42
LocalLibrary@       dev@                mach_kernel.nonY2K
Net/                drives/             private/
NextAdmin/          etc@                tmp@
NextApps/           lib/                usr/
NextDeveloper@      lost+found/
NextLibrary/        mach@

(note there is only one "/U")

# ls /U[tab]
# ls /U

# ls /drives/
IBM3/   win95/

# ls /drives/I[tab]
# ls /drives/I

NOTE: I can't build zsh again, I keep getting errors about files that end  
with .pro not existing (ie prompt.pro) and it dies.

I don't know how I did it before.

TjL

Re: yet another undesired 3.1.5-pws-15 change

[Peter Stephenson]

Timothy J Luoma wrote:
> There's still a problem with my PROMPT:
> 
> PROMPT='
> ---------------------------------------- %t/%T  
> ----------------------------------------
> %S[OLDPWD: $OLDPWD]
>    [PWD: %~]%s
> %B%n$LOCAL_HOST%b $REMOTE_HOST
> '
> 
> it produces an extra blank line at the end (unlike 3.1.4)

I didn't dare fix this when I originally spotted it, but I think the answer
is the following.  It doesn't have any immediately obvious ill effects.

--- Src/Zle/zle_refresh.c.pw	Mon Apr 19 09:59:35 1999
+++ Src/Zle/zle_refresh.c	Sun Apr 25 15:30:02 1999
@@ -327,7 +327,7 @@
             vcs = 0;
         else if (!clearflag && lpromptbuf[0]) {
             zputs(lpromptbuf, shout);
-	    if (lpromptw == 0)
+	    if (lpromptw == 0 && lprompth == 1)
 		zputs("\n", shout);	/* works with both hasam and !hasam */
 	}
 	if (clearflag) {
@@ -947,7 +947,7 @@
 		zputc('\r', shout);
 	    tc_upcurs(lprompth - 1);
 	    zputs(lpromptbuf, shout);
-	    if (lpromptw == 0)
+	    if (lpromptw == 0 && lprompth == 1)
 		zputs("\n", shout);	/* works with both hasam and !hasam */
 	}
 	i = lpromptw;

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

Re: yet another undesired 3.1.5-pws-15 change

[Geoff Wing]

Peter Stephenson <pws@ibmth.df.unipi.it> typed:
:Timothy J Luoma wrote:
:> There's still a problem with my PROMPT:
:> PROMPT='
:> ---------------------------------------- %t/%T  
:> ----------------------------------------
:> %S[OLDPWD: $OLDPWD]
:>    [PWD: %~]%s
:> %B%n$LOCAL_HOST%b $REMOTE_HOST
:> '
:> it produces an extra blank line at the end (unlike 3.1.4)
:
:I didn't dare fix this when I originally spotted it, but I think the answer
:is the following.  It doesn't have any immediately obvious ill effects.
:-	    if (lpromptw == 0)
:+	    if (lpromptw == 0 && lprompth == 1)
: 		zputs("\n", shout);	/* works with both hasam and !hasam */

This can't really work, can it.  Say your term width is 80 and your prompt
is 80 chars long, then lpromptw == 0 && lprompth == 2.  Now the cursor is
sitting at the right column and wants to be in the left column, but you've
just avoided putting it there and if you don't have automargin (hasam == 1)
then you're stuffed.  There needs to be a method to differentiate between
having your cursor at 0 and at 80 which probably isn't in there now but
shouldn't be hard to add.  I'll look at doing a patch for this now.

Regards,
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : (Australia) 0413 431 874 <<<new
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/