completion listing and singlelinezle. Not!

completion listing and singlelinezle. Not!

[Peter Stephenson]

A colleague pointed out to me that somebody on comp.unix.shell found out
that singlelinezle completely screws up completion listings.  They were
using 4.0.4, but it's still that way.  It doesn't depend on old or new
completion, nor on alwayslastprompt (which they didn't seem to know
about).  I can understand that alwayslastprompt wouldn't work too well if
you can't go up, but completion listings should surely work.

I tried back in 3.0.6 (pre-installed on this Solaris 5.8 system) and it
sort-of worked, without alwayslastprompt behaviour, but there is an odd bug
that the display doesn't get refreshed properly until you type another
character.  I hope that's an old bug we don't need to worry about any
more.

I can't get news myself here, so can't pass on the message or email.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: completion listing and singlelinezle. Not!

[Clint Adams]

> I can't get news myself here, so can't pass on the message or email.

I think this is it.

====
From: Ferdinand Goldmann <Ferdinand.Goldmann@zid.uni-linz.ac.at>
Subject: zsh singlelinezle feature
Newsgroups: comp.unix.shell

Hello *,

I have a question concerning the singlelinezle option of zsh.
When turned on, the list-choices function does not work anymore. Why?
I am running zsh in ksh emulation, and this is quite an annoyance.

Also, the list of choices is displayed below the prompt. Can this be
configured to be displayed above the prompt? I am using zsh 4.0.4.

TIA!
-- 
>> Ferdinand Goldmann
>> EMail:  Ferdinand.Goldmann@zid.uni-linz.ac.at
>> Tel. : +43/732/2468/9398 Fax. : +43/732/2468/9397

Re: completion listing and singlelinezle. Not!

[Sven Wischnowsky]

Peter Stephenson wrote:

> A colleague pointed out to me that somebody on comp.unix.shell found out
> that singlelinezle completely screws up completion listings.  They were
> using 4.0.4, but it's still that way.  It doesn't depend on old or new
> completion, nor on alwayslastprompt (which they didn't seem to know
> about).  I can understand that alwayslastprompt wouldn't work too well if
> you can't go up, but completion listings should surely work.
> 
> I tried back in 3.0.6 (pre-installed on this Solaris 5.8 system) and it
> sort-of worked, without alwayslastprompt behaviour, but there is an odd bug
> that the display doesn't get refreshed properly until you type another
> character.  I hope that's an old bug we don't need to worry about any
> more.
> 
> I can't get news myself here, so can't pass on the message or email.

As far as I can see in zrefresh(), with singlelinezle it gives up
(zle_refresh.c:394ff) before coming to the code that decides whether
the list has to be displayed (line 650).


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

PATCH: completion listing and singlelinezle

[Geoff Wing]

Sven Wischnowsky <wischnow@berkom.de> typed:
: Peter Stephenson wrote:
:> A colleague pointed out to me that somebody on comp.unix.shell found out
:> that singlelinezle completely screws up completion listings.  They were

:> I tried back in 3.0.6 (pre-installed on this Solaris 5.8 system) and it
:> sort-of worked, without alwayslastprompt behaviour, but there is an odd bug
:> that the display doesn't get refreshed properly until you type another
:> character.  I hope that's an old bug we don't need to worry about any
:> more.

Seems to be gone.  Could repro in 3.0.8 but not in 4.*
 
: As far as I can see in zrefresh(), with singlelinezle it gives up
: (zle_refresh.c:394ff) before coming to the code that decides whether
: the list has to be displayed (line 650).

Found out that zle_refresh.c didn't have any goto statements in it yet
so I thought I better do one :-)

Index: Src/Zle/zle_refresh.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_refresh.c,v
retrieving revision 1.4
diff -u -r1.4 zle_refresh.c
--- Src/Zle/zle_refresh.c	24 Oct 2001 07:00:49 -0000	1.4
+++ Src/Zle/zle_refresh.c	14 Feb 2002 05:20:41 -0000
@@ -393,7 +393,7 @@
 
     if (termflags & TERM_SHORT) {
 	singlerefresh();
-	return;
+	goto singlelineout;
     }
 
     if (cs < 0) {
@@ -643,6 +643,7 @@
     onumscrolls = numscrolls;
     if (nlnct > vmaxln)
 	vmaxln = nlnct;
+singlelineout:
     fflush(shout);		/* make sure everything is written out */
 
     /* if we have a new list showing, note it; if part of the list has been
@@ -1183,7 +1184,6 @@
     qbuf = nbuf;
     nbuf = obuf;
     obuf = qbuf;
-    fflush(shout);		/* make sure everything is written out */
 }
 
 /**/

Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>

Re: PATCH: completion listing and singlelinezle

[Peter Stephenson]

Geoff Wing wrote:
> : As far as I can see in zrefresh(), with singlelinezle it gives up
> : (zle_refresh.c:394ff) before coming to the code that decides whether
> : the list has to be displayed (line 650).
> 
> Found out that zle_refresh.c didn't have any goto statements in it yet
> so I thought I better do one :-)

The patch certainly seems to do the trick... I don't think anything more
sophisticated is needed with singlelinezle.  If you commit this, I'll
produce 4.1.0-dev-4, since it's high time.  It could also go on the 4.0
line.

There's no target date for 4.1.1; I'm still vaguely waiting for some
major change to justify it, in particular improvements in the parameter
code to make things like discipline functions easier.  But every time I
look at the code I stop looking at it after a bit.  The only vague
conclusion I've come to is that it might be a good idea to use some form
of vtable for storing stuff common to all parameters of a particular
type, which would save a bit of space with negligible impact on
performance.  But since discipline functions have to be specific to
individual parameters, it doesn't help us there at all.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

4.1.1 timescale, longer term ideas

[Oliver Kiddle]

 --- Peter Stephenson <pws@csr.com> wrote: 

> There's no target date for 4.1.1; I'm still vaguely waiting for some
> major change to justify it, in particular improvements in the

I'd agree that there needs to be more by way of significant changes in
4.1 before we can justify a 4.1.1. After 4.1.1, I'd suggest that we do
away with -dev releases and have fairly regular 4.1.x releases. -dev
releases were very valuable before we had CVS and daily snapshots and
when they came out fortnightly. Now, we just seem to have rather a lot
of choices between stable releases and bleeding edge from cvs.

> parameter
> code to make things like discipline functions easier.

The biggest problem facing us with respect to allowing discipline
functions is the complete lack of function scoping or some other way to
associate functions to variables unambiguously.

> But every time I
> look at the code I stop looking at it after a bit.  The only vague
> conclusion I've come to is that it might be a good idea to use some
> form
> of vtable for storing stuff common to all parameters of a particular

That sounds similar to the ideas I had. I was thinking of an OO like
solution and of making other aspects of the shell (such as functions
and traps) be in effect a type of parameter. There might then only be
one set of code for scoping etc. I concluded with the nameref stuff I
never finished that it might be easier to start again with the
parameter code if we want the other ksh93 features too. But if it is
going to be rewritten then it'd seem sensible to try to add unicode
support at the same time. I think our best approach to handling unicode
would be first to decide where we will use what encoding (UTF-8/wchars
etc), add autoconf handling with a --enable option and then fix
different parts of the code as and when until, after some time, we're
finished. Now, if I could just find myself a job that didn't involve 5
hours on the train every day, I might have time to actually do some of
this.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: PATCH: completion listing and singlelinezle

[Clint Adams]

> The patch certainly seems to do the trick... I don't think anything more
> sophisticated is needed with singlelinezle.  If you commit this, I'll
> produce 4.1.0-dev-4, since it's high time.  It could also go on the 4.0
> line.

The 4.0 rdiff is about 104k; might be nice to have a 4.0.5 too.

RE: PATCH: completion listing and singlelinezle

[Borsenkow Andrej]

> There's no target date for 4.1.1; I'm still vaguely waiting for some
> major change to justify it, in particular improvements in the
parameter
> code to make things like discipline functions easier. 

Something needs to be done with module dependencies as well. Because
object-pure does not work (you can't load module with unresolved data
even on Linux), we can't help using some external description files for
modules with dependencies info in them


-andrej