PATCH: line count imprecision in calclist()

PATCH: line count imprecision in calclist()

[Clint Adams]

To recreate, run zsh -f in an 80x24, compctl (to load completion modules),
and then the following:

mkdir -p /tmp/xxxxx/yyy/zzzzz
cd /tmp/xxxxx/yyy/zzzzz
touch aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
touch bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
touch cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
touch ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
touch eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
touch fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
touch gggg
touch hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
touch iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
touch jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
touch kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
touch lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
touch mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
mkdir ppppppp


You should now have a situation wherein you can type

ls /tmp/xxxxx/yyy/zzzzz/<TAB>

and find your cursor a line too high.  Behavior is normal if no scrolling
occurs.  If you rename the i+ file to something two characters shorter,
the cursor will be two lines too high.

It seems to have something to do with
 	glines += 1 + ((1 + mlens[m->gnum]) / columns);
in calclist() when mlens[m->gnum] is 79 (and therefore glines += 2).


This seems to correct the problem..

--- compresult.c        1999/11/05 09:10:44     1.1.1.3
+++ compresult.c        1999/11/08 03:05:58
@@ -1287,7 +1287,7 @@
                                if (!(m->flags & CMF_DISPLINE))
                                    glines += 1 + (mlens[m->gnum] / columns);
                            } else if (!(m->flags & CMF_NOLIST))
-                               glines += 1 + ((1 + mlens[m->gnum]) / columns);
+                               glines += 1 + ((mlens[m->gnum]) / columns);
                        }
                }
            }

However, it makes me uneasy that something will break elsewhere.

Re: PATCH: line count imprecision in calclist()

[Sven Wischnowsky]

Clint Adams wrote:

> ...
> 
> You should now have a situation wherein you can type
> 
> ls /tmp/xxxxx/yyy/zzzzz/<TAB>
> 
> and find your cursor a line too high.  Behavior is normal if no scrolling
> occurs.  If you rename the i+ file to something two characters shorter,
> the cursor will be two lines too high.
> 
> It seems to have something to do with
>  	glines += 1 + ((1 + mlens[m->gnum]) / columns);
> in calclist() when mlens[m->gnum] is 79 (and therefore glines += 2).
> 
> 
> This seems to correct the problem..
> 
> --- compresult.c        1999/11/05 09:10:44     1.1.1.3
> +++ compresult.c        1999/11/08 03:05:58
> @@ -1287,7 +1287,7 @@
>                                 if (!(m->flags & CMF_DISPLINE))
>                                     glines += 1 + (mlens[m->gnum] / columns);
>                             } else if (!(m->flags & CMF_NOLIST))
> -                               glines += 1 + ((1 + mlens[m->gnum]) / columns);
> +                               glines += 1 + ((mlens[m->gnum]) / columns);
>                         }
>                 }
>             }
> 
> However, it makes me uneasy that something will break elsewhere.

No, I think that's ok (apart from: I couldn't apply the patch, due to
some whitespace difference I guess, and apart from: the patch should
have been relative to the toplevel directory -- always having to cd or 
to type paths when patch asks which file to patch is a bit annoying).

Due to the way such matches are (or should be) printed, the `1 +' was
indeed wrong, just the same as the line two lines above the one you
changed.

Bye
 Sven


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