* Re: yet another undesired 3.1.5-pws-15 change
@ 1999-04-23 10:59 Sven Wischnowsky
1999-04-24 3:11 ` Timothy J Luoma
0 siblings, 1 reply; 10+ messages in thread
From: Sven Wischnowsky @ 1999-04-23 10:59 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: yet another undesired 3.1.5-pws-15 change
1999-04-23 10:59 yet another undesired 3.1.5-pws-15 change Sven Wischnowsky
@ 1999-04-24 3:11 ` Timothy J Luoma
1999-04-25 13:44 ` Peter Stephenson
[not found] ` <990423234917.ZM30140@candle.brasslantern.com>
0 siblings, 2 replies; 10+ messages in thread
From: Timothy J Luoma @ 1999-04-24 3:11 UTC (permalink / raw)
To: Sven Wischnowsky; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: yet another undesired 3.1.5-pws-15 change
1999-04-24 3:11 ` Timothy J Luoma
@ 1999-04-25 13:44 ` Peter Stephenson
1999-04-25 14:35 ` Geoff Wing
[not found] ` <990423234917.ZM30140@candle.brasslantern.com>
1 sibling, 1 reply; 10+ messages in thread
From: Peter Stephenson @ 1999-04-25 13:44 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: yet another undesired 3.1.5-pws-15 change
1999-04-25 13:44 ` Peter Stephenson
@ 1999-04-25 14:35 ` Geoff Wing
1999-04-25 15:22 ` PATCH: 3.1.5-pws-15: multiline prompt Geoff Wing
0 siblings, 1 reply; 10+ messages in thread
From: Geoff Wing @ 1999-04-25 14:35 UTC (permalink / raw)
To: zsh-workers
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* PATCH: 3.1.5-pws-15: multiline prompt
1999-04-25 14:35 ` Geoff Wing
@ 1999-04-25 15:22 ` Geoff Wing
0 siblings, 0 replies; 10+ messages in thread
From: Geoff Wing @ 1999-04-25 15:22 UTC (permalink / raw)
To: zsh-workers
Heyla,
see discussion under "yet another undesired 3.1.5-pws-15 change"
This should do what you want:
*** prompt.c.org Thu Nov 12 03:04:38 1998
--- prompt.c Mon Apr 26 01:15:25 1999
***************
*** 232,238 ****
break;
case 'l':
*bp = '\0';
! countprompt(bufline, &t0, 0);
if (t0 >= arg)
test = 1;
break;
--- 232,238 ----
break;
case 'l':
*bp = '\0';
! countprompt(bufline, &t0, 0, 0);
if (t0 >= arg)
test = 1;
break;
***************
*** 678,688 ****
/**/
void
! countprompt(char *str, int *wp, int *hp)
{
int w = 0, h = 1;
int s = 1;
for(; *str; str++) {
if(*str == Meta)
str++;
if(*str == Inpar)
--- 678,692 ----
/**/
void
! countprompt(char *str, int *wp, int *hp, int overf)
{
int w = 0, h = 1;
int s = 1;
for(; *str; str++) {
+ if(w >= columns) {
+ w = 0;
+ h++;
+ }
if(*str == Meta)
str++;
if(*str == Inpar)
***************
*** 694,705 ****
else if(s) {
if(*str == '\t')
w = (w | 7) + 1;
! else if(*str == '\n')
! w = columns;
! else
w++;
}
! if(w >= columns) {
w = 0;
h++;
}
--- 698,712 ----
else if(s) {
if(*str == '\t')
w = (w | 7) + 1;
! else if(*str == '\n') {
! w = 0;
! h++;
! } else
w++;
}
! }
! if(w >= columns) {
! if (!overf || w > columns) {
w = 0;
h++;
}
*** Zle/zle_refresh.c.org Tue Apr 13 18:07:18 1999
--- Zle/zle_refresh.c Mon Apr 26 01:11:29 1999
***************
*** 96,101 ****
--- 96,102 ----
olnct, /* previous number of lines */
ovln, /* previous video cursor position line */
lpromptw, rpromptw, /* prompt widths on screen */
+ lpromptwof, /* left prompt width with real end position */
lprompth, /* lines taken up by the prompt */
rprompth, /* right prompt height */
vcs, vln, /* video cursor position column & line */
***************
*** 141,148 ****
*obuf[ln] = '\0';
}
! countprompt(lpromptbuf, &lpromptw, &lprompth);
! countprompt(rpromptbuf, &rpromptw, &rprompth);
if (lpromptw) {
memset(nbuf[0], ' ', lpromptw);
--- 142,155 ----
*obuf[ln] = '\0';
}
! countprompt(lpromptbuf, &lpromptwof, &lprompth, 1);
! countprompt(rpromptbuf, &rpromptw, &rprompth, 0);
! if (lpromptwof != winw)
! lpromptw = lpromptwof;
! else {
! lpromptw = 0;
! lprompth++;
! }
if (lpromptw) {
memset(nbuf[0], ' ', lpromptw);
***************
*** 327,333 ****
vcs = 0;
else if (!clearflag && lpromptbuf[0]) {
zputs(lpromptbuf, shout);
! if (lpromptw == 0)
zputs("\n", shout); /* works with both hasam and !hasam */
}
if (clearflag) {
--- 334,340 ----
vcs = 0;
else if (!clearflag && lpromptbuf[0]) {
zputs(lpromptbuf, shout);
! if (lpromptwof == winw)
zputs("\n", shout); /* works with both hasam and !hasam */
}
if (clearflag) {
***************
*** 947,953 ****
zputc('\r', shout);
tc_upcurs(lprompth - 1);
zputs(lpromptbuf, shout);
! if (lpromptw == 0)
zputs("\n", shout); /* works with both hasam and !hasam */
}
i = lpromptw;
--- 954,960 ----
zputc('\r', shout);
tc_upcurs(lprompth - 1);
zputs(lpromptbuf, shout);
! if (lpromptwof == winw)
zputs("\n", shout); /* works with both hasam and !hasam */
}
i = lpromptw;
--
Geoff Wing <gcw@pobox.com> Mobile : (Australia) 0413 431 874 <<<new
Work URL: http://www.primenet.com.au/ Ego URL: http://pobox.com/~gcw/
^ permalink raw reply [flat|nested] 10+ messages in thread
* success (mostly) pws 17 under NeXTStep 3.3
[not found] ` <990504100735.ZM28408@candle.brasslantern.com>
@ 1999-05-11 2:40 ` Timothy J Luoma
1999-05-11 8:06 ` Peter Stephenson
0 siblings, 1 reply; 10+ messages in thread
From: Timothy J Luoma @ 1999-05-11 2:40 UTC (permalink / raw)
To: zsh-workers
Using regular NeXT 3.3 'cc' and 'make'
configure ok
make dies with '.pro' errors
(see http://www.peak.org/~luomat/misc/zsh/zsh-failed.log.gz if you want to
see all output)
Then I had a thought: "try gnumake"
That seemed to work (GNU Make version 3.74)!!
(it failed at the end, after making 'zsh' -- I think because I don't have
the 'yodl' program -- shouldn't it recognize that and not try and build the
documentation?)
1) it fixed the $lapps thing (ie I get a / at the end with I do 'cd $la[tab]'
2) it fixed the $PROMPT problem (no more blank space at the end of $PROMPT)
However
It still did not fix the completion problem where directories are being ignored:
# /bin/ls -F /
LocalApps/ etc/
LocalLibrary/ lib/
Net/ lost+found/
NextAdmin/ mach@
NextApps/ mach_kernel
NextDeveloper/ mach_kernel.OS42
NextLibrary/ mach_kernel.nonY2K
Users/ private/
bin/ tmp/
dev/ unlabeled/
drives/ usr/
# /bin/ls -F /U[tab]
# /bin/ls -F /U[cursor still here]
(ALL of the other files in / complete successfully)
BUT maybe there is a clue!
# df /Users
Filesystem Size Used Avail Capacity Mounted on
/dev/sd1b 994M 437M 457M 49% /Users
You will notice that /Users is not on / but is a separate partition
Notice that this problem ALSO occurs with /drives/IBM3 which is ALSO a
mounted directory:
# /bin/ls -F /drives/
IBM3/ win95/
# /bin/ls -F /drives/I[tab]
# /bin/ls -F /drives/I[cursor here]
(note: /drives/win95 is a vmount'd drive)
Now unfortunately this theory dies for /usr/local and /usr/local/Archive
which are also not on the same partition as / but I still think it is a clue
of some sort:
Here's my 'df' output:
Filesystem Size Used Avail Capacity Mounted on
/dev/rsd0h 984M 866M 118M 88% /drives/win95
/dev/sd2a 392M 128M 225M 36% /private/swapdisk
/dev/sd1b 994M 437M 457M 49% /Users
/dev/sd3b 1.3G 840M 359M 70% /usr/local/Archive
/dev/sd1a 994M 701M 194M 78% /
/dev/sd3a 1.3G 835M 364M 70% /usr/local
/dev/sd3c 1.3G 32M 1.1G 3% /drives/IBM3
And here's something still more interesting.
After I printed that 'df' I then did this:
# mount -t 4.3 /dev/sd0a /drives/kickdisk
and then look what happens now:
# /bin/ls -F /drives/[tab]
# /bin/ls -F /drives/kickdisk/
I don't claim to understand this, but that's all the information I can give
you. Here's the final 'df' output:
Filesystem Size Used Avail Capacity Mounted on
/dev/rsd0h 984M 866M 118M 88% /drives/win95
/dev/sd0a 6.6M 241K 6.0M 4% /drives/kickdisk
/dev/sd1a 994M 701M 194M 78% /
/dev/sd1b 994M 437M 457M 49% /Users
/dev/sd2a 392M 128M 225M 36% /private/swapdisk
/dev/sd3a 1.3G 835M 364M 70% /usr/local
/dev/sd3b 1.3G 840M 359M 70% /usr/local/Archive
/dev/sd3c 1.3G 32M 1.1G 3% /drives/IBM3
Any clues appreciated
TjL
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: success (mostly) pws 17 under NeXTStep 3.3
1999-05-11 2:40 ` success (mostly) pws 17 under NeXTStep 3.3 Timothy J Luoma
@ 1999-05-11 8:06 ` Peter Stephenson
0 siblings, 0 replies; 10+ messages in thread
From: Peter Stephenson @ 1999-05-11 8:06 UTC (permalink / raw)
To: zsh-workers
Timothy J Luoma wrote:
> Using regular NeXT 3.3 'cc' and 'make'
>
> configure ok
>
> make dies with '.pro' errors
That's a strange make, since it hasn't built the .pro files at all, which
are in the dependencies for zsh.mdh.
> (it failed at the end, after making 'zsh' -- I think because I don't have
> the 'yodl' program -- shouldn't it recognize that and not try and build the
> documentation?)
In the released version, the documentation is up to date, so that yodl is
only necessary if you alter the files. You can avoid this here by getting
hold of the .doc.tar file from the same place and untarring it on top of
the source code.
> Users/ private/
>
> # /bin/ls -F /U[tab]
> # /bin/ls -F /U[cursor still here]
>
> (ALL of the other files in / complete successfully)
The code in question is in get_matches_files() in Src/Zle/zle_tricky.c.
The main possibilities are that either zreaddir() and hence readdir() are
missing out Users, in which case ls probably wouldn't show it up, or that
the stat() call later on fails and the directory is skipped. You can test
the effect of stat() if you have compiled zsh with dynamically loaded
libraries, by using `zmodload stat; stat -rs /Users', or see the main
README file about how to get the file stat.so compiled into the base
executable. Maybe ls -ld /Users would give a clue, since that's basically
a stat() as well.
Another possibility is that the macro access(..., F_OK) is failing. The
following shell code should do exactly the same check:
[[ -e /Users ]] && print file exists || print file doesn\'t exist
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: yet another undesired 3.1.5-pws-15 change
1999-04-28 18:13 ` Wayne Davison
@ 1999-04-30 23:24 ` Timothy J Luoma
0 siblings, 0 replies; 10+ messages in thread
From: Timothy J Luoma @ 1999-04-30 23:24 UTC (permalink / raw)
To: Wayne Davison; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: yet another undesired 3.1.5-pws-15 change
1999-04-23 10:14 yet another undesired 3.1.5-pws-15 change Timothy J Luoma
@ 1999-04-28 18:13 ` Wayne Davison
1999-04-30 23:24 ` Timothy J Luoma
0 siblings, 1 reply; 10+ messages in thread
From: Wayne Davison @ 1999-04-28 18:13 UTC (permalink / raw)
To: Timothy J Luoma; +Cc: zsh-workers
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..
^ permalink raw reply [flat|nested] 10+ messages in thread
* yet another undesired 3.1.5-pws-15 change
@ 1999-04-23 10:14 Timothy J Luoma
1999-04-28 18:13 ` Wayne Davison
0 siblings, 1 reply; 10+ messages in thread
From: Timothy J Luoma @ 1999-04-23 10:14 UTC (permalink / raw)
To: zsh-workers
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1999-05-11 8:31 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-23 10:59 yet another undesired 3.1.5-pws-15 change Sven Wischnowsky
1999-04-24 3:11 ` Timothy J Luoma
1999-04-25 13:44 ` Peter Stephenson
1999-04-25 14:35 ` Geoff Wing
1999-04-25 15:22 ` PATCH: 3.1.5-pws-15: multiline prompt Geoff Wing
[not found] ` <990423234917.ZM30140@candle.brasslantern.com>
[not found] ` <199904241324.JAA23300@ocalhost>
[not found] ` <990424092703.ZM32177@candle.brasslantern.com>
[not found] ` <199904302157.RAA26524@ocalhost>
[not found] ` <990504100735.ZM28408@candle.brasslantern.com>
1999-05-11 2:40 ` success (mostly) pws 17 under NeXTStep 3.3 Timothy J Luoma
1999-05-11 8:06 ` Peter Stephenson
-- strict thread matches above, loose matches on Subject: below --
1999-04-23 10:14 yet another undesired 3.1.5-pws-15 change Timothy J Luoma
1999-04-28 18:13 ` Wayne Davison
1999-04-30 23:24 ` Timothy J Luoma
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).