starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Goto EOL sets cursor before, not after last char in line #10258

New Issue
Closed
opened 2026-01-31 02:16:35 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 02:16:35 +00:00
Owner
Copy Link

Originally created by @tj64 on GitHub (Aug 22, 2020).

Win32NT 10.0.19041.0 Microsoft Windows NT 10.0.19041.0

Windows Terminal
Version: 1.1.2021.0

Any other software?
I see this under

  • WSL2 Debian unstable as well as
  • on a remote Archlinux Server (via ssh from WT)

I see this in 3 different editors with VIM Keybindings:
Spacemacs, Vim, Vip (Picolisp)

Steps to reproduce

  1. Type "$" (= goto EOL in Vim Keybindings)

Expected behavior

(given: no space after last char in line): cursor jumps to position after last character of line

Actual behavior

cursor jumps to position before last character of line, i.e. for a line of 20 chars the $ command sets the cursor after char 19 and before char 20, not after char 20

Originally created by @tj64 on GitHub (Aug 22, 2020). Win32NT 10.0.19041.0 Microsoft Windows NT 10.0.19041.0 Windows Terminal Version: 1.1.2021.0 Any other software? I see this under - WSL2 Debian unstable as well as - on a remote Archlinux Server (via ssh from WT) I see this in 3 different editors with VIM Keybindings: Spacemacs, Vim, Vip (Picolisp) # Steps to reproduce 1. Type "$" (= goto EOL in Vim Keybindings) # Expected behavior (given: no space after last char in line): cursor jumps to position **after** last character of line # Actual behavior cursor jumps to position **before** last character of line, i.e. for a line of 20 chars the $ command sets the cursor after char 19 and before char 20, not after char 20
claunia added the Resolution-By-DesignResolution-ExternalNeeds-Tag-Fix labels 2026-01-31 02:16:35 +00:00
claunia commented 2026-01-31 02:16:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 22, 2020):

Unfortunately, this is by design and reproduces in gvim/xvim/macvim even outside of a terminal. This is documented in motion.txt:

$  or <End>		To the end of the line.  When a count is given also go
			[count - 1] lines downward. |inclusive| motion.
			In Visual mode the cursor goes to just after the last
			character in the line.
			When 'virtualedit' is active, "$" may move the cursor
			back from past the end of the line to the last
			character in the line.

It looks like it operates by setting the "wanted" cursor position to some absurdly large number, but because the cursor can't actually be beyond the end of the line unless you're in visual mode or have virtualedit set properly, it will cap out at the last visible column.

@DHowett commented on GitHub (Aug 22, 2020): Unfortunately, this is by design and reproduces in gvim/xvim/macvim even outside of a terminal. This is documented in `motion.txt`: ``` $ or <End> To the end of the line. When a count is given also go [count - 1] lines downward. |inclusive| motion. In Visual mode the cursor goes to just after the last character in the line. When 'virtualedit' is active, "$" may move the cursor back from past the end of the line to the last character in the line. ``` It looks like it operates by setting the "wanted" cursor position to some absurdly large number, but because the cursor can't actually be beyond the end of the line unless you're in visual mode or have virtualedit set properly, it will cap out at the last visible column.
claunia commented 2026-01-31 02:16:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 22, 2020):

Spacemacs and vip are, of course, faithfully emulating vim's behavior here.

@DHowett commented on GitHub (Aug 22, 2020): Spacemacs and vip are, of course, faithfully emulating vim's behavior here.
claunia commented 2026-01-31 02:16:36 +00:00
Author
Owner
Copy Link

@tj64 commented on GitHub (Aug 24, 2020):

Hello, thx for you answer.
Not sure what you mean by "by design", would that be "by editor design"?
At least in Vip, which is core vim in just 1500 sloc pure picolisp, there is not much design involved, it all boils down to:

(prin "^[[1;3H")

when moving the cursor with $ on line 1 with content ABC.
Just printing the Ansi CUP csi.

The difference I see is that in

  • linux terminal the cursor sits on top of the chars
  • win term the cursor sits before the char (or between two chars)
    cursor pos at the end of the ABC line is the same though (1,3), and line copying actually works in win term too.

So things do work, it was just visually irritating to have an apparently unaccesible char at the end of each line.

@tj64 commented on GitHub (Aug 24, 2020): Hello, thx for you answer. Not sure what you mean by "by design", would that be "by editor design"? At least in Vip, which is core vim in just 1500 sloc pure picolisp, there is not much design involved, it all boils down to: `(prin "^[[1;3H")` when moving the cursor with $ on line 1 with content ABC. Just printing the Ansi CUP csi. The difference I see is that in - linux terminal the cursor sits on top of the chars - win term the cursor sits before the char (or between two chars) cursor pos at the end of the ABC line is the same though (1,3), and line copying actually works in win term too. So things do work, it was just visually irritating to have an apparently unaccesible char at the end of each line.
claunia commented 2026-01-31 02:16:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 24, 2020):

Sorry, maybe I don't understand? I do mean "by editor design."

Is this a report that the bar cursor shape appears to be between characters? Here's what I see in vim with various cursor shapes.

empty box

image

filled box

image

underscore

image

bar

image

This might seem strange, but it is true of all terminal emulators that support the bar cursor. Here I've tested 3 others:

gnome-terminal

image

konsole

image

xterm

image

Can you share a screenshot of the issue you're reporting?

@DHowett commented on GitHub (Aug 24, 2020): Sorry, maybe I don't understand? I do mean "by editor design." Is this a report that the `bar` cursor shape appears to be between characters? Here's what I see in vim with various cursor shapes. ### empty box ![image](https://user-images.githubusercontent.com/189190/91076992-2fce0300-e5f5-11ea-9a6f-dd588c9d5966.png) ### filled box ![image](https://user-images.githubusercontent.com/189190/91077033-3d838880-e5f5-11ea-96e3-914cf4e33b80.png) ### underscore ![image](https://user-images.githubusercontent.com/189190/91077050-483e1d80-e5f5-11ea-8fa3-d85de105b745.png) ### bar ![image](https://user-images.githubusercontent.com/189190/91077071-4f652b80-e5f5-11ea-988a-b5d82945b4ac.png) This might seem strange, but it is true of all terminal emulators that support the bar cursor. Here I've tested 3 others: ### gnome-terminal ![image](https://user-images.githubusercontent.com/189190/91077408-da462600-e5f5-11ea-9f7a-fb0098d06782.png) ### konsole ![image](https://user-images.githubusercontent.com/189190/91077466-f2b64080-e5f5-11ea-92fa-35664c0e0c92.png) ### xterm ![image](https://user-images.githubusercontent.com/189190/91077358-c8648300-e5f5-11ea-9daa-7f7541ff7163.png) Can you share a screenshot of the issue you're reporting?
claunia commented 2026-01-31 02:16:36 +00:00
Author
Owner
Copy Link

@tj64 commented on GitHub (Aug 24, 2020):

Hallo, it's all fine actually, I wasn't aware of the different cursor shapes, and before using win term obviously had a box shape on all my systems, and then a bar shape on win term (without customizing something), and that caused my irritation.
Thank you for pointing that out!

@tj64 commented on GitHub (Aug 24, 2020): Hallo, it's all fine actually, I wasn't aware of the different cursor shapes, and before using win term obviously had a box shape on all my systems, and then a bar shape on win term (without customizing something), and that caused my irritation. Thank you for pointing that out!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Resolution-By-Design Resolution-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#10258
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?