Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSReadLine doesn't respect cursor position when using cmd+k or cmd+l on macOS #4074

Open
3 tasks done
daprahamian opened this issue Jul 16, 2024 · 5 comments
Open
3 tasks done

Comments

@daprahamian
Copy link

Prerequisites

  • Write a descriptive title.
  • Make sure you are able to repro it on the latest released version
  • Search the existing issues, especially the pinned issues.

Exception report

N/A

Screenshot

Screen.Recording.2024-07-16.at.3.41.21.PM.mov

Environment data

PS Version: 7.4.2
PS HostName: ConsoleHost
PSReadLine Version: 2.3.5
PSReadLine EditMode: Emacs
OS: Darwin Dans-MacBook-Pro.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020 arm64
BufferWidth: 80
BufferHeight: 24

Steps to reproduce

  1. Set the following key handler
Set-PSReadlineKeyHandler -Chord 'Control+a' -ScriptBlock {
  [Console]::SetCursorPosition(5, 5)
}
  1. Set prompt to null
function prompt { "`0" }
  1. Clear screen. Your cursor should now be in the top left corner
Clear-Host
  1. Hit Ctrl+a. Your cursor should now be at position 5,5

  2. Type Write-Output

Expected behavior

The shell would display Write-Output starting at position 5,5

Actual behavior

The cursor moves back to position 1,1 and displays Write-Output there

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage 🔍 It's a new issue that core contributor team needs to triage. label Jul 16, 2024
@daxian-dbw
Copy link
Member

PSReadLine doesn't handle the case where the cursor is moved from outside of PSReadLine (cursor movement from a custom key handler is also considered outside of PSReadLine). It doesn't simply write at the current cursor position but tracking the initial cursor position and calculate where it should render for the text. So, I'd say the reported scenario is not supported.

@daxian-dbw daxian-dbw removed the Needs-Triage 🔍 It's a new issue that core contributor team needs to triage. label Aug 5, 2024
@daprahamian
Copy link
Author

Thanks for the reply @daxian-dbw. In that case, what is the proper mechanism for adjusting the cursor position of PSReadline?

@daxian-dbw
Copy link
Member

PSReadLine's cursor position is supposed to be adjusted only by its cursor movement key bindings, such as Home, End, LeftArrow, Ctrl+LeftArrow, and etc.

@daprahamian
Copy link
Author

that seems like a pretty limited view of what one can do in a terminal, and by extension what PSReadline should be obligated to handle. There are multiple cases when a terminal application can change the position of the cursor, and it seems like a poor user experience to ignore those.

As another example, hitting Cmd+K or Cmd+L in the Mac terminal app clears the screen, and in the case of Cmd+K moves the cursor to the top of the screen along with a fresh prompt. PSReadline does not respect this and continues typing in the last location.

It seems like PSReadline should either respect the current cursor position within the terminal, or it should have an API that allows the cursor position to be moved.

@daxian-dbw daxian-dbw reopened this Aug 6, 2024
@daxian-dbw daxian-dbw changed the title PSReadLine does not appear to respect cursor position of shell PSReadLine doesn't respect cursor position when using cmd+k or cmd+l on macOS Aug 6, 2024
@daxian-dbw
Copy link
Member

PSReadLine handles cursor movement due to resizing of the terminal window and a special case where a TUI clears the screen (see code here). But unfortunately, it doesn't handle cmd+k and cmd+l on mac. I'm not sure if we can perfectly support cmd+k because PSReadLine allows multi-line input and if the cursor is in the middle of a multi-line input, cmd+k will only keep the line where the cursor is at. It looks zsh doesn't handle that case well either.

But I think we should support cmd+k and cmd+l if there is no input yet or if the input fits in the current row on terminal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants