Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Zle display bug with LONG expansions
- X-seq: zsh-workers 1615
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Zoltan Hidvegi <hzoli@xxxxxxxxxx>
- Subject: Re: Zle display bug with LONG expansions
- Date: Thu, 11 Jul 1996 15:18:02 -0700
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: Zoltan Hidvegi <hzoli@xxxxxxxxxx> "Re: Zle display bug with LONG expansions" (Jul 11, 8:32pm)
- References: <199607111832.UAA03358@xxxxxxxxxxxxxxxxx>
- Reply-to: schaefer@xxxxxxx
On Jul 11, 8:32pm, Zoltan Hidvegi wrote:
} Subject: Re: Zle display bug with LONG expansions
}
} > In an 80x32 (or smaller?) xterm, do the following:
} >
} > zagzig[38] echo **/*<TAB>
}
} zle doen not handle the case when a line does not fit onto the screen.
Well, I know it doesn't handle it the way it does when a line does fit,
but it's obviously trying to do *something*.
} Geoff told me that for some reason zsh have to know in advance wether the
} current terminal automatically wraps the line. He is probably right since
} some terminals start a new line when a character is printed in the last
} column while most terminals start a new line only is a character is printed
} after the last column.
Right; if zsh doesn't know about autowrap, and tries to print a newline
after the $COLUMNS'th character, you could end up with blank lines between
each two displayed lines.
But if zsh knows enough to avoid printing the newline because the terminal
autowraps, then it also ought to be able to avoid this.
Just mention it in etc/BUGS if nobody knows how to fix it ...
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.nbn.com/people/lantern
New male in /home/schaefer:
>N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"
Messages sorted by:
Reverse Date,
Date,
Thread,
Author