Significant prompt flick with fzf --expect

tmpm697 commented 2 weeks ago

Checklist

[X] I have read through the manual page (man fzf)
[X] I have searched through the existing issues
[X] For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of `fzf --version`

0.53.0 (0.53.0)

OS

[ ] Linux
[X] macOS
[ ] Windows
[ ] Etc.

Shell

[X] bash
[X] zsh
[X] fish

Problem / Steps to reproduce

To capture the key press I use a map/list/array in shells for whatever it called like bellow:

var result = [(echo "1\n\2\n3" | fzf --expect=ctrl-h)]   # [] is an array or list
var key = $result[0]
var fuzzy = $result[1]

compare to non --expect and no need to bring array/list, above code is significant cause shell to redraw prompt more.

junegunn commented 2 weeks ago

I don't know what you mean by that. Do you have a video capture of the problem you're experiencing?

LangLangBart commented 1 week ago

@tmpm697 The maintainer dedicates their time and effort to support this project. Ignoring their requests for information while opening new issues is disrespectful. Please respond to queries on existing issues before creating new ones.

tmpm697 commented 1 week ago

@tmpm697 The maintainer dedicates their time and effort to support this project. Ignoring their requests for information while opening new issues is disrespectful. Please respond to queries on existing issues before creating new ones.

It's not, I'm trying to gathering info, but this is something that I sometime observing, but not quite of sure, but flick is real issue to me.

tmpm697 commented 1 week ago

this issue kinda hard to trace, i saw more prompt flick than usual with #3869 usage, but spread couple of days check back and forth, i have this info:

All shells only support full redraw or partially, i.e: redisplay, reset prompt (in zsh) which sloppily force redraw screen which cause flick, this is by design I think, original ppl who created terminal protocols or shells want flick to distinguish something is update but this should not be the case in 2024

Unfortunately I didn't find a solution for this in which shells give hints or obvious protocols for external programs to redraw screen in exact and cleanliness way.

fzf --no-clear still requires a redraw from shells in which it will move cursor at start of prompt and then update prompt's content again which causes a light flick which still a flick.

Workaround solutions like tput to send fzf to another screen or give it fullscreen is not a solution, no one ever should doing that as it's sloppy, give more flick due to clear screen and draw fzf's contents again.

So for the conclusion: either fix from terminal for better protocols or shells to expose hints for external program to draw correctly, but i guess they want to play blame game instead of write down some text :)

junegunn / fzf