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: Problem with cursor position after wrapped completion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

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

Err, this works for me -- of course the completion code takes care to
count the lines (including wrapping) correctly. However, this will
only work if the COLUMNS parameter is correctly set (and the terminal
doesn't do automatic word-wrapping like your mailer ;-).

Are you sure that your COLUMNS information is correct?

Bye
 Sven


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

Re: Problem with cursor position after wrapped completion lists

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Err, this works for me -- of course the completion code takes care to
> count the lines (including wrapping) correctly. However, this will

I tried it again and it seemed to work fine in the new xterms and
aixterms which I created but after looking back in the aixterm where I'd
had the problems, I realised what the cause was. There was one
line in the list which was exactly 80 ($COLUMNS) characters wide.

xterm and aixterm seem to treat this differently: aixterm gives me a blank
line after it whereas xterm doesn't. Zsh then places the cursor correctly
only with the xterm.

Another thing which I've noticed in this process is that if my prompt is 79
($COLUMNS-1) characters wide, and I use xterm, the cursor initially appears
over the last character of my prompt and when I type, the text wraps back
over the beginning of the prompt.

> only work if the COLUMNS parameter is correctly set (and the terminal
> doesn't do automatic word-wrapping like your mailer ;-).

Sorry about that wrapped mail, I'll attempt to avoid it next time I send a patch.

Peter Stephenson wrote:
> By the way, it's high time I pointed out that sending me a copy of a
> message going to any of the zsh lists is futile as they get sorted into the
> same folder and I just have to delete one.

This is because my mailer includes both the sender and the mailing list (CC'd)
in the receipients when I press reply. I'll try to remember to cut your
address out in future.

Oliver Kiddle

RE: Problem with cursor position after wrapped completion lists

[Andrej Borsenkow]

>
> I tried it again and it seemed to work fine in the new xterms and
> aixterms which I created but after looking back in the aixterm where I'd
> had the problems, I realised what the cause was. There was one
> line in the list which was exactly 80 ($COLUMNS) characters wide.
>

Back in the past there was exactly this problem with Zle - if displayed line was
exactly screen-width long, output was wrong. It was fixed by Geoff in a  patch
4855 (I just looked up in archive).

Sven, could you check if something from this patch is aplicable in this case?

>
> Peter Stephenson wrote:
> > By the way, it's high time I pointed out that sending me a copy of a
> > message going to any of the zsh lists is futile as they get sorted into the
> > same folder and I just have to delete one.
>

Well, I am sorry for this as well ... but you see, to send _reply_ to
zsh-workers that is in To: header I have to hit "reply-to-all" - there is no
other possibility


And exactly for this I'm using procmail with formail filter that eliminates
duplicates (as long, as message-id is preserved) - so I get exactly one copy of
all duplicates.

/andrej

Re: Problem with cursor position after wrapped completion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I tried it again and it seemed to work fine in the new xterms and
> aixterms which I created but after looking back in the aixterm where I'd
> had the problems, I realised what the cause was. There was one
> line in the list which was exactly 80 ($COLUMNS) characters wide.
> 
> xterm and aixterm seem to treat this differently: aixterm gives me a blank
> line after it whereas xterm doesn't. Zsh then places the cursor correctly
> only with the xterm.

Hm. I've had a look at this: the only solution I see is to make the
code check if the line it just printed is COLUMNS characters long
whenever it wants to print a newline. Since there are several ways how 
the different things are printed (display-lists, explanation strings, 
matches), fixing this can get quite ugly, so I better ask first: does
anybody see a better solution than to keep track of the number of
characters printed?

Bye
 Sven


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

RE: Problem with cursor position after wrapped completion lists

[Andrej Borsenkow]

>
> Hm. I've had a look at this: the only solution I see is to make the
> code check if the line it just printed is COLUMNS characters long
> whenever it wants to print a newline. Since there are several ways how
> the different things are printed (display-lists, explanation strings,
> matches), fixing this can get quite ugly, so I better ask first: does
> anybody see a better solution than to keep track of the number of
> characters printed?
>

No. There are two types of terminals. Some ttys wrap immediately after you
printed exactly COLUMNS lines. Some of them wrap first when COLUMNS+1th
character is printed. It means, that after you printed exactly COLUMNS of
characters you do not know, if your cursor is placed on current or next line. As
I have no idea if terminal description inludes such information, the only clean
way to solve it is to explicitly position cursor after exactly COLUMNS
characters were printed. Have you got a look at 4855? Among other things, it
makes Zsh to output '\r' in this case. Weird as it is, it works in both cases.
In the former case, additional character triggers new line; in the latter, we
are already on the new line so nothing changes. Note, that if you output
COLUMNS-1 or COLUMNS+1 characters, you won't get problem at all.

Note, that it only marginally relates to am attrubute. Both types of terminals I
have seen _did_ have am :-)

I believe, that fixing it may be hard but not ugly. The best would be to have
just one function that prints out all sort of output ... dunno, if this is
currently possible.

/andrej

RE: Problem with cursor position after wrapped completion lists

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> I believe, that fixing it may be hard but not ugly. The best would be to have
> just one function that prints out all sort of output ... dunno, if this is
> currently possible.

Yes, I had a look at 4855 and the solution was clear, of course, but
we can't simply use one function for all cases because we don't want
that: explanation strings have to handle %-escapes, display-lists
should be printed literally, and matches should be printed in a way
that is called (in the code) `nice' (as in `nicezputs()').

Ok, so I'll have to bite the bullet...

Bye
 Sven

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

RE: Problem with cursor position after wrapped completion lists

[Andrej Borsenkow]

>
> Yes, I had a look at 4855 and the solution was clear, of course, but
> we can't simply use one function for all cases because we don't want
> that: explanation strings have to handle %-escapes, display-lists
> should be printed literally, and matches should be printed in a way
> that is called (in the code) `nice' (as in `nicezputs()').
>

Ahem, I meant "one function that handles low level interaction with physical
display". All others should (ideally) simply update virtual screen, and then
call one single "refresh", that finally paints it.

Just midsummer dreams :-)

/andrej