The shell prompt get offsets every time an item was accepted

[nophDog]

It's happening months ago when I started to use PSFzf, I don't know what's going on behind the scene and it just didn't behave like expected, because when the prompt stays at the bottom of terminal, it got offset each time an item is accepted, looks weird.

I didn't see a related issue here. (If there was a disscussion, please let me know : )

[mattcargile]

I don't really think there is a fix for this. Every time you hit <ENTER> the prompt has to be redrawn and space for fzf output has to be allotted when you are at the bottom of the terminal. Maybe the redrawing of the prompt could be smarter though that seems complicated.

See the below function for the redrawn prompt.

PSFzf/PSFzf.Base.ps1

Lines 122 to 135 in 0364b14

	#HACK: workaround for fact that PSReadLine seems to clear screen
	# after keyboard shortcut action is executed, and to work around a UTF8
	# PSReadLine issue (GitHub PSFZF issue #71)
	function InvokePromptHack()
	{
	$previousOutputEncoding = [Console]::OutputEncoding
	[Console]::OutputEncoding = [Text.Encoding]::UTF8
	try {
	[Microsoft.PowerShell.PSConsoleReadLine]::InvokePrompt()
	} finally {
	[Console]::OutputEncoding = $previousOutputEncoding
	}
	}

[nophDog]

Thanks for your explain and so we have to wait the official team of psreadline to fix :(

I don't really think there is a fix for this. Every time you hit <ENTER> the prompt has to be redrawn and space for fzf output has to be allotted when you are at the bottom of the terminal. Maybe the redrawing of the prompt could be smarter though that seems complicated.

[mattcargile]

Well maybe. You also have a two lined prompt which is different than mine. Are you using startship to draw your prompt or oh-my-posh? Additionally, what version and apps are you using below? It could be related to that. It looks like you are typing higher order Unicode characters too and it appears you are hitting ESC which causes the prompt to jump anyway and rewrite differently because of fzf when you are at the bottom of the terminal window.

Version PSReadline :
Version of _PowerShell:
Version and Terminal Application?

[nophDog]

Well maybe. You also have a two lined prompt which is different than mine.

I'm not sure if this made a difference so I tested again with command pwsh -noprofile version on both Windows Terminal and Hyper Terminal, here's the gif.

(The Hyper Terminal gif is too big somehow, so I didn't upload it but it's almost the same result

Are you using startship to draw your prompt or oh-my-posh?

Yes, I am using starship for now, but it should not affect cause this time I used pwsh -noprofile to launch a subshell, right?

It looks like you are typing higher order Unicode characters too

I am a Chinese and '空格' means 'Space' key, that's probably not the problem

---

Version PSReadline :
Version of _PowerShell:
Version and Terminal Application?

Version PSReadline : 2.2.6
Version of _PowerShell: 7.3.0
Version and Terminal Application: 1.15.2875.0
Windows Version: Windows 11 Pro WorkStation
OS Version: 22621.900

[mattcargile]

Looks like our version are matching well except I am Win 10 22H2 running single line oh-my-posh.

That gif looks like it is working like it should. No? Even your original gif didn't appear all that off. The problem is when your prompt gets to the bottom and has to "jump"?

[nophDog]

The problem is when your prompt gets to the bottom and has to "jump"?

Exactly, it won't work as expected when the prompt stays at the bottom of terminal.

[mattcargile]

Ah ok, so you don't want all that white space generating as you go in and out of fzf.

Hmm. I wonder if this module can hook into some class in PSReadline or the like and try to rewrite the prompt where it was instead of at the bottom? I don't know if that information is available.

[nophDog]

I wonder if this module can hook into some class in PSReadline or the like and try to rewrite the prompt where it was instead of at the bottom?

Sorry but I do know little about PowerShell and I am not a developer :(

Just let me know if you need help or else.

[5HT2]

Any updates on this? I'm experiencing this on macOS pwsh if I can help debug

[mattcargile]

I don't even remember what the issue really was. I was trying to read through and I can't tell if OP wants the prompt line to stay in place when fzf is called or actually jump back to its original location.

[daephx]

I've been following this issue for a while, since I have a very similar bug which has led me to removing the recommended tab expansion key handler Set-PSReadLineKeyHandler -Key Tab -ScriptBlock { Invoke-FzfTabCompletion } because it doesn't function in a way that I find acceptable.

Subsequent calls to Invoke-FzfTabCompletion through this handler will create an extraneous amount of whitespace between the active prompt and the last prompt/command output. This also occurs whenever Ctrl-c is pressed to cancel the fzf menu.

This also does not appear to be an issue with the Ctrl-r binding for selecting command history.

PSVersion: 7.4.5
PSReadLine: 2.3.5
PSFzf: 2.6.1

I can also confirm that I can reproduce this in both my personal config and when using pwsh --noprofile.

1. Start PowerShell without user profile: pwsh --noprofile
2. Ensure the module is imported: Import-Module -Name PSFzf
3. Register the key handler: Set-PSReadLineKeyHandler -Key Tab -ScriptBlock { Invoke-FzfTabCompletion }
4. Press Tab to invoke the handler, where | is the cursor position: gci -|
5. Either accept an entry or press Ctrl-c to allow fzf to close.

Here is the comparison between PSFzf and the Zsh plugin Aloxaf/fzf-tab:

PSFzf	fzf-tab

[mattcargile]

Hmm. I wonder if using straight fzf in pwsh would cause the same issues. This is to say maybe the start-process wrapper is messing stuff up. Could just be PSReadline or the terminal.

[daephx]

I haven't ever noticed this issue being present with direct calls to fzf, but I do need to correct my earlier statement about ctrl-r for command history -- it also exhibits the problem, I just didn't notice it until I tried a few more times.

With my testing, It seems the issue occurs more accurately when the prompt is repositioned to accommodate the fzf --height flag (mine is set to 60%). Your earlier suggestion aligns with what I’m seeing.

Hmm. I wonder if this module can hook into some class in PSReadline or the like and try to rewrite the prompt where it was instead of at the bottom? I don't know if that information is available.

I agree - ideally, the prompt should inherit the new position, rather than returning to its previous one. But if that information is not exposed, then I'm even more unsure as to how this can be solved.
Hopefully, I at least jogged your memory!