Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: 'zle redisplay' bug in 5.3?
- X-seq: zsh-workers 40272
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: Zsh Hackers' List <zsh-workers@xxxxxxx>
- Subject: Re: 'zle redisplay' bug in 5.3?
- Date: Thu, 05 Jan 2017 15:01:35 +0000
- Cms-type: 201P
- In-reply-to: <170105010914.ZM1529@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- Organization: Samsung Cambridge Solution Centre
- References: <20170105030137.v4tzweda6pxyqnrq@majutsushi.net> <CGME20170105091042epcas1p3ebc6c107d3121c8f6b980bbcbc59bc60@epcas1p3.samsung.com> <170105010914.ZM1529@torch.brasslantern.com>
On Thu, 5 Jan 2017 01:09:14 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Jan 5, 4:01pm, Jan Larres wrote:
> }
> } expand-or-complete-with-dots() {
> } echo -ne "\e[31m......\e[0m"
> } zle expand-or-complete
> } zle redisplay
> } }
>
> Hmm. Indeed, with multi-line prompts, invoking redisplay immediately
> after a completion menu is displayed will move the cursor upward as
> many extra lines as the prompt is tall but then does not finish the
> repainting of the prompt, leaving the cursor in the wrong place.
>
> You don't even need compinit, just do:
>
> % PS1=$':first line\n'"$PS1"
> :first line
> % ls <TAB>
> :first line
> % ls <M-x redisplay><RET>
>
> and you'll observe zle get confused.
>
> This is from workers/38048z ... where I asked for additional feedback
> and got none ... discussion starts in users/21315.
>
> I suspect something is different about the complist module vs. plain
> completion menu and the change in 38048 does not account for the
> latter.
I don't know anything about this beyond the fact that showinglist has
three values: off, an extra special clever value (-1), and an extra extra
special very very clever value (-2), and no normal values (> 0) because
that wouldn't be clever enough.
The documentation says
/* Most lines of the buffer we've shown at once with the current list *
* showing. == 0 if there is no list. == -1 if a new list has just *
* been put on the screen. == -2 if zrefresh() needs to put up a new *
* list. */
/**/
mod_export int showinglist;
Is it a case of the two requiring different handling? You might have
thought the different behaviour was the one where the new list was
needed as in the other cases the screen is already in a consistent state
(perhaps?) Something like the following?
pws
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 8d173cd..49ce154 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -2434,8 +2434,13 @@ redisplay(UNUSED(char **args))
moveto(0, 0);
zputc(&zr_cr); /* extra care */
tc_upcurs(lprompth - 1);
- resetneeded = !showinglist;
- clearflag = showinglist;
+ if (showinglist == -2) {
+ resetneeded = 0;
+ clearflag = 1;
+ } else {
+ resetneeded = 1;
+ clearflag = 0;
+ }
return 0;
}
Messages sorted by:
Reverse Date,
Date,
Thread,
Author