Problem with cursor position after wrapped completion lists

Problem with cursor position after wrapped completion lists

[Oliver Kiddle]

The completion lists (as generated from the -Y option) don't work very
well when lines wrap at the end of the line:

cd ~+<tab>

If the list then contains lots of stupidly long pathnames some of which
wrap at the end of the terminal. For example:
0      
/home/ccm/ccmlib/ccmlib_d_log_file_libraries.ss/b3_stubs.wrk/ccm_test_utilities
1      
/home/native_rs6000/test/ccmcda/ccmlm0_log_manager.ss/okiddle.wrk/ccmlm0
etc...

The cursor is then placed a couple of lines below where it should be
because the wrapping has caused it to be lower than zsh thinks it is.

I suppose the only way of fixing this is by controlling the wrapping
directly from zsh unless there is a way of knowing how the terminal is
dealing with lines wider than the terminal (wrapping or truncating
them).

Note that I am not to blame for the directory structure we have here
and that I could solve the problem for myself by modifying _tilde to
compact the directory's names to use references to various associative
arrays and variables which I have: so don't bother suggesting that I
use a few 'hash -d's or shorter directory names.

Oliver Kiddle

Big problems RE: Problem with cursor position after wrapped completion lists

[Andrej Borsenkow]

Actually, list display does not work at all if terminal does not do automargins
(and even if it correctly says it in terminfo) and size of a single match exeeds
COLUMNS-2 (the is the last size that works). List display thinks that terminal
always does am (at least, this is how I interpret this) and gets number of lines
wrong and moves cursor far above original prompt :-) If you can switch am off,
just try it - it is funny.

/andrej

Re: Big problems RE: Problem with cursor position after wrapped completion lists

[Sven Wischnowsky]

mason@primenet.com.au wrote:

> The biggest problem is that we can't always know where we are.  Anyone who
> does ``setopt NO_PROMPT_CR'' on an abnormal (or uncommon) terminal is just
> asking for it.

In the refresh-code, yes. With completion listings this is easier and
there we need only some information what we have to print to get to
the beginning of the next line.

Bye
 Sven


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

Re: Big problems RE: Problem with cursor position after wrapped completion lists

[Geoff Wing]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
:mason@primenet.com.au wrote:
:> I'm pretty sure zle_refresh.c violates this in some special cases (prompt
:> things I think) so I guess I better fix those soonish.  Printing outside of
:> zle_refresh.c I've got no idea about.
:I'll just wait for this solution and then hack the completion listing
:code, we'll probably end up with some utility functions that at least
:try to return some information about the current cursor-position or
:the number of characters printed in this process. Then we can decide
:what else we want to do with them.

The biggest problem is that we can't always know where we are.  Anyone who
does ``setopt NO_PROMPT_CR'' on an abnormal (or uncommon) terminal is just
asking for it.

If we get too more complex we'd just about end up incorporating a ``screen''
clone :-)

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Big problems RE: Problem with cursor position after wrapped completion lists

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Note the extra "  " at the end of every match that is listed. I have no idea,
> where it comes from. Probably, without this extra " " nobody would even notice
> this problem.

setopt listtypes, I guess.

> Actually, list display does not work at all if terminal does not do automargins
> (and even if it correctly says it in terminfo) and size of a single match exeeds
> COLUMNS-2 (the is the last size that works). List display thinks that terminal
> always does am (at least, this is how I interpret this) and gets number of lines
> wrong and moves cursor far above original prompt :-) If you can switch am off,
> just try it - it is funny.

There is also a bit of extra padding at the end of each match. With
normal listing this shouldn't be printed for the last match of each
line, but with complist it is (to have the right margin nicely aligned 
if someone sets the bcakground colour).

mason@primenet.com.au wrote:

> I'm pretty sure zle_refresh.c violates this in some special cases (prompt
> things I think) so I guess I better fix those soonish.  Printing outside of
> zle_refresh.c I've got no idea about.

I'll just wait for this solution and then hack the completion listing
code, we'll probably end up with some utility functions that at least
try to return some information about the current cursor-position or
the number of characters printed in this process. Then we can decide
what else we want to do with them.

Bye
 Sven


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