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

Unable to select text after exiting vim from git #16321

New Issue
Open
opened 2026-01-31 05:04:06 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 05:04:06 +00:00
Owner
Copy Link

Originally created by @kevinoid on GitHub (Jan 2, 2022).

Windows Terminal version

Unable to reproduce in wt

Windows build number

10.0.19043.1415

Other Software

Git 2.34.1
Vim 8.2.3951 (Note: Issue does not occur using vim bundled with git.)

Steps to reproduce

  1. Run cmd or pwsh
  2. Observe that text can be selected with the mouse.
  3. Run git -c core.editor=C:\\Windows\\vim.bat config --system --edit
  4. Type :q to exit vim.
  5. Observe that text can not be selected with the mouse.

Expected Behavior

Text would be selectable, as it was before running git/vim.

Actual Behavior

Text is not selectable without switching to mark mode.

Originally created by @kevinoid on GitHub (Jan 2, 2022). ### Windows Terminal version Unable to reproduce in wt ### Windows build number 10.0.19043.1415 ### Other Software [Git 2.34.1](https://github.com/git-for-windows/git/releases/download/v2.34.1.windows.1/Git-2.34.1-64-bit.exe) [Vim 8.2.3951](https://github.com/vim/vim-win32-installer/releases/download/v8.2.3951/gvim_8.2.3951_x64.exe) (Note: Issue does not occur using vim bundled with git.) ### Steps to reproduce 1. Run `cmd` or `pwsh` 2. Observe that text can be selected with the mouse. 3. Run `git -c core.editor=C:\\Windows\\vim.bat config --system --edit` 4. Type `:q` to exit vim. 5. Observe that text can not be selected with the mouse. ### Expected Behavior Text would be selectable, as it was before running git/vim. ### Actual Behavior Text is not selectable without switching to mark mode.
claunia added the Product-ConhostIssue-BugArea-ServerPriority-2 labels 2026-01-31 05:04:06 +00:00
claunia commented 2026-01-31 05:04:07 +00:00
Author
Owner
Copy Link

@kevinoid commented on GitHub (Jan 2, 2022):

Note: I've been unable to reproduce the issue with vim alone or with the version of vim bundled with git. It appears to be specific to standalone vim invoked by git.

@kevinoid commented on GitHub (Jan 2, 2022): Note: I've been unable to reproduce the issue with vim alone or with the version of vim bundled with git. It appears to be specific to standalone vim invoked by git.
claunia commented 2026-01-31 05:04:07 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (Jan 3, 2022):

@kevinoid what's the content of your C:\Windows\vim.bat file?

@elsaco commented on GitHub (Jan 3, 2022): @kevinoid what's the content of your `C:\Windows\vim.bat` file?
claunia commented 2026-01-31 05:04:07 +00:00
Author
Owner
Copy Link

@kevinoid commented on GitHub (Jan 3, 2022):

@elsaco Sorry about that. I forgot that it's created by the Vim installer only if certain options are checked. The content is:

@echo off
rem -- Run Vim --
rem # uninstall key: vim82 #

setlocal
set VIM_EXE_DIR=C:\Program Files\Vim\vim82
if exist "%VIM%\vim82\vim.exe" set VIM_EXE_DIR=%VIM%\vim82
if exist "%VIMRUNTIME%\vim.exe" set VIM_EXE_DIR=%VIMRUNTIME%

if not exist "%VIM_EXE_DIR%\vim.exe" (
    echo "%VIM_EXE_DIR%\vim.exe" not found
    goto :eof
)

"%VIM_EXE_DIR%\vim.exe"  %*

However, I observe the same issue when running. git -c core.editor="C:\\Program\ Files\\Vim\\vim82\\vim.exe" config --system --edit without the batch file.

@kevinoid commented on GitHub (Jan 3, 2022): @elsaco Sorry about that. I forgot that it's created by the Vim installer only if certain options are checked. The content is: ```bat @echo off rem -- Run Vim -- rem # uninstall key: vim82 # setlocal set VIM_EXE_DIR=C:\Program Files\Vim\vim82 if exist "%VIM%\vim82\vim.exe" set VIM_EXE_DIR=%VIM%\vim82 if exist "%VIMRUNTIME%\vim.exe" set VIM_EXE_DIR=%VIMRUNTIME% if not exist "%VIM_EXE_DIR%\vim.exe" ( echo "%VIM_EXE_DIR%\vim.exe" not found goto :eof ) "%VIM_EXE_DIR%\vim.exe" %* ``` However, I observe the same issue when running. `git -c core.editor="C:\\Program\ Files\\Vim\\vim82\\vim.exe" config --system --edit` without the batch file.
claunia commented 2026-01-31 05:04:07 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (Jan 3, 2022):

With vim 8.2.3988 (latest GitHub release) and Windows 10 was not able to repro:

https://user-images.githubusercontent.com/3933920/147894408-18045b11-5954-4190-aa8b-17c6f3434c91.mp4

@elsaco commented on GitHub (Jan 3, 2022): With `vim 8.2.3988` (latest GitHub release) and Windows 10 was not able to repro: https://user-images.githubusercontent.com/3933920/147894408-18045b11-5954-4190-aa8b-17c6f3434c91.mp4
claunia commented 2026-01-31 05:04:07 +00:00
Author
Owner
Copy Link

@kevinoid commented on GitHub (Jan 3, 2022):

@elsaco Did you test in conhost? My apologies for being unclear. I'm also unable to reproduce in Windows Terminal.

@kevinoid commented on GitHub (Jan 3, 2022): @elsaco Did you test in conhost? My apologies for being unclear. I'm also unable to reproduce in Windows Terminal.
claunia commented 2026-01-31 05:04:08 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (Jan 3, 2022):

Using conhost after executing git config --system --edit the mouse selection is not working. For some reason that command disables QuickEdit Mode and Insert Mode. If I toggle those setting mouse selection works again. The editor was set to micro:

core.editor=c:\\tools\\micro\\micro.exe

just to test with a different editor. Same result if -c core.editor option is used.

In conhost please check Properites before and after running the command.

@elsaco commented on GitHub (Jan 3, 2022): Using `conhost` after executing `git config --system --edit` the mouse selection is not working. For some reason that command disables `QuickEdit Mode` and `Insert Mode`. If I toggle those setting mouse selection works again. The editor was set to `micro`: `core.editor=c:\\tools\\micro\\micro.exe` just to test with a different editor. Same result if `-c core.editor` option is used. In `conhost` please check `Properites` before and after running the command.
claunia commented 2026-01-31 05:04:08 +00:00
Author
Owner
Copy Link

@kevinoid commented on GitHub (Jan 3, 2022):

Interesting! Thanks @elsaco. Same behavior here. After further testing:

  1. core.editor="C:\\Program\ Files\\Vim\\vim82\\vim.exe" Leaves QuickEdit
  2. core.editor="C:\\Path\\To\\micro.exe" (Micro 2.0.10) Leaves in QuickEdit
  3. core.editor="C:\\Program\ Files\\Vim\\vim82\\gvim.exe" Stays in QuickEdit
  4. core.editor=C:\\Windows\\notepad.exe Stays in QuickEdit
  5. core.editor="C:\\Program\ Files\\Git\\usr\\bin\\vim.exe" Stays in QuickEdit
  6. core.editor="C:\\Program\ Files\\Git\\usr\\bin\\nano.exe" Stays in QuickEdit

It appears that the issue occurs for non-Cygwin console applications? Any idea why that might be the case?

I've opened https://github.com/git-for-windows/git/issues/3607 to ask the Git developers for assistance. Feel free to follow-up there and/or close this issue if you are convinced the issue is in Git.

@kevinoid commented on GitHub (Jan 3, 2022): Interesting! Thanks @elsaco. Same behavior here. After further testing: 1. `core.editor="C:\\Program\ Files\\Vim\\vim82\\vim.exe"` Leaves QuickEdit 2. `core.editor="C:\\Path\\To\\micro.exe"` ([Micro 2.0.10](https://github.com/zyedidia/micro/releases/tag/v2.0.10)) Leaves in QuickEdit 3. `core.editor="C:\\Program\ Files\\Vim\\vim82\\gvim.exe"` Stays in QuickEdit 4. `core.editor=C:\\Windows\\notepad.exe` Stays in QuickEdit 5. `core.editor="C:\\Program\ Files\\Git\\usr\\bin\\vim.exe"` Stays in QuickEdit 6. `core.editor="C:\\Program\ Files\\Git\\usr\\bin\\nano.exe"` Stays in QuickEdit It appears that the issue occurs for non-Cygwin console applications? Any idea why that might be the case? I've opened https://github.com/git-for-windows/git/issues/3607 to ask the Git developers for assistance. Feel free to follow-up there and/or close this issue if you are convinced the issue is in Git.
claunia commented 2026-01-31 05:04:09 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 3, 2022):

This is likely due to msys/cygwin's management of the console mode coupled with vim's new code to disable/re-enable quickedit mode when the mouse is enabled.

Overall, cygwin does WAY too much mode management and it messes a bunch of stuff up.

@DHowett commented on GitHub (Jan 3, 2022): This is likely due to msys/cygwin's management of the console mode coupled with vim's new code to disable/re-enable quickedit mode when the mouse is enabled. Overall, cygwin does WAY too much mode management and it messes a bunch of stuff up.
claunia commented 2026-01-31 05:04:09 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 3, 2022):

Copying from the discussion over in git land:

I added a trace point in SetConsoleMode. Here's what I found!

image

In order, by the number in Line#, starting with 2.

  1. cmd enables 0x80 (EXTENDED_FLAGS) but doesn't change other modes (INSERT, QUICK_EDIT and AUTO_POSITION are on)
  2. sh enables 0x100 (VIRTUAL_TERMINAL_INPUT)
  3. sh disables 0x100
  4. sh enables 0x8 (WINDOW_INPUT)
  5. sh clears all modes except 1, 2, 4, 8 (PROCESSED, LINE, ECHO, WINDOW)
    • IMPORTANT: Since sh did not use EXTENDED_FLAGS, the INSERT, QUICK_EDIT and AUTO_POSITION flags are not touched.
  6. vim sets EXTENDED_FLAGS, disabling the three modes mentioned in "6-Important"
  1. vim restores the mode it got on startup, keeping EXTENDED_FLAGS set so as to leave INSERT, QUICK_EDIT and AUTO_POSITION disabled.

Looking at the logic in conhost, it seems as though it might be our fault in the end. 😁 When you call SetConsoleMode without specifying EXTENDED_FLAGS, we will never reply to you by including EXTENDED_FLAGS (and therefore, none of the extended flags). In step 6, sh calls SetConsoleMode(0xF) -- no EXTENDED_FLAGS -- so when vim calls GetConsoleMode we gladly report that all extended flags are turned off. . . which vim remembers until it exits, and when it restores them to what it thought it should... it turns them off.

@DHowett commented on GitHub (Jan 3, 2022): Copying from the discussion over in git land: I added a trace point in `SetConsoleMode`. Here's what I found! <img width="844" alt="image" src="https://user-images.githubusercontent.com/189190/147976080-7775912f-7992-4125-9e20-577e56aec23e.png"> In order, by the number in Line#, starting with 2. 2. cmd enables 0x80 (`EXTENDED_FLAGS`) but doesn't change other modes (`INSERT`, `QUICK_EDIT` and `AUTO_POSITION` are on) 3. sh enables 0x100 (`VIRTUAL_TERMINAL_INPUT`) 4. sh disables 0x100 5. sh enables 0x8 (`WINDOW_INPUT`) 6. sh clears all modes except 1, 2, 4, 8 (`PROCESSED`, `LINE`, `ECHO`, `WINDOW`) * **IMPORTANT:** Since sh did not use `EXTENDED_FLAGS`, the `INSERT`, `QUICK_EDIT` and `AUTO_POSITION` flags are not touched. 7. vim sets `EXTENDED_FLAGS`, disabling the three modes mentioned in "6-Important" --- 23. vim restores the mode it got on startup, keeping `EXTENDED_FLAGS` set so as to leave `INSERT`, `QUICK_EDIT` and `AUTO_POSITION` disabled. Looking at the logic in conhost, it seems as though it _might_ be our fault in the end. 😁 When you call SetConsoleMode without specifying `EXTENDED_FLAGS`, we will never reply to you by _including_ `EXTENDED_FLAGS` (and therefore, none of the extended flags). In step 6, sh calls `SetConsoleMode(0xF)` -- no `EXTENDED_FLAGS` -- so when vim calls `GetConsoleMode` we gladly report that all extended flags are turned off. . . which vim remembers until it exits, and when it restores them to what it thought it should... it turns them off.
claunia commented 2026-01-31 05:04:09 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Jan 3, 2022):

Relevant contribution from (my hero) Michal Necasek: https://www.os2museum.com/wp/disabling-quick-edit-mode/

I haven't found a way to reliably query QUICK_EDIT, and without being able to query, it's impossible to reliably restore either. I think Michal came to the same conclusion, with a much more thorough analysis.

@malxau commented on GitHub (Jan 3, 2022): Relevant contribution from (my hero) Michal Necasek: https://www.os2museum.com/wp/disabling-quick-edit-mode/ I haven't found a way to reliably query QUICK_EDIT, and without being able to query, it's impossible to reliably restore either. I think Michal came to the same conclusion, with a much more thorough analysis.
claunia commented 2026-01-31 05:04:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 6, 2022):

Wow CONSOLE_USE_PRIVATE_FLAGS is kind of a disaster ain't it?

Is there any good way to fix this that won't unreasonably break someone who was already relying on this madness? Or maybe this is so mental that there's no reasonable way that someone would have relied on this current behavior?

@zadjii-msft commented on GitHub (Jan 6, 2022): Wow `CONSOLE_USE_PRIVATE_FLAGS` is kind of a disaster ain't it? Is there any good way to fix this that won't unreasonably break someone who was already relying on this madness? Or maybe this is so _mental_ that there's no reasonable way that someone would have relied on this current behavior?
claunia commented 2026-01-31 05:04:09 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2022):

I was chatting with @miniksa about what we could do here -- it might be as "simple" as exposing the private flags to apps that aren't expecting them (since they should have been doing either (1) backup and restore or (2) bitwise manipulation). This won't help Vim today.

@DHowett commented on GitHub (Jan 6, 2022): I was chatting with @miniksa about what we could do here -- it might be as "simple" as exposing the private flags to apps that aren't expecting them (since they should have been doing either (1) backup and restore or (2) bitwise manipulation). This won't help Vim today.
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 Area-Server Issue-Bug Priority-2 Product-Conhost
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#16321
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?