Issues on VimChangeCaretWidth

[rcmdnk]

Caret width can be changed only on the specific applications: Wordpad, Word, OneNote, or Explorer. On Notepad, the caret width is kept but does not change.

For the most of other applications, the caret width is kept as original width.

When this option is enabled, the current window briefly loses focus when the mode is changed.

• Enable on other applications (maybe need to use another method, specific on applications or?)
• Revert the width when the forcus is changed to the vim_ahk disabled applications

[BlueDrink9]

On Notepad, the caret width is kept but does not change.

Strange, my Win 10 notepad was what I tested the feature in and it worked fine.

Revert the width when the forcus is changed to the vim_ahk disabled applications

It is currently hooking into the same timer that the mode indicator icon uses. Ideally, both of these should instead detect a window change and update then, rather than periodically checking a timer. This is possible with AHK (I have written a library that can cal a callback function when the active window changes) but it is a little unreliable in some situations (like full-screen applications). We could look at implementing that instead, which would allow a once-off cursor change when an ahk disabled window is focused.

[rcmdnk]

Strange, my Win 10 notepad was what I tested the feature in and it worked fine.

Really? It may depend on the system (language...?)

This gif shows how it works in my environment ( sorry, application names are Japanese Left upper: Wordpad (the caret change works well) Left lower: Notpad (the caret width is kept) Right: Evernote (the caret is thin (default) in any cases) )

Why I do not want to enable VimChangeCaretWidth as default is that the caret is kept thick until I go to some applications like Wordpad and change the mode to Insert mode.

But maybe this happens only in my environment...?

If so, maybe above my concerns are irrelevant.

If it works differently in environments of yorus and mine, I'm sorry maybe there was misunderstanding in the disucssions in the previous PR.

But I'm not sure on which environment it works on Notepad...?

[BlueDrink9]

Why I do not want to enable VimChangeCaretWidth as default is that the caret is kept thick until I go to some applications like Wordpad and change the mode to Insert mode.

Yeah, that's a limitation of the current system. We can't know they have changed windows. I think the only difference I'm seeing is in Notepad. Maybe we should check what the class is?

[rcmdnk]

Widnows Spy shows Notepad like:

ahk_class Notepad
ahk_exe notepad.exe

[BlueDrink9]

What about the edit class?

[rcmdnk]

Do you mean ClassNN value in Focused Control of Window Spy? It shows like ClassNN: Edit1 for Notepad.

[BlueDrink9]

Yeah, that's what I meant. Next time I'm on windows, I'll check it's the same on mine. I should also double check on the master branch rather than on my fork, JIC

[codeRSH]

I am having a similar issue.

When I move to applications which don't use vim_ahk, the caret width remains same as what I left in application under vim_ahk control (eg. Notepad).

Is it possible to keep the caret width constant (i.e. Pipe) for non-relevant applications and only change caret width as per the mode in Applications under vim_ahk control only (Notepad, OneNote etc.) ?

[rcmdnk]

sorry, but I have no idea for now. The command works only when the frontmost application is one of the specific applications such as Wordpad.

It means, if we want to keep the caret width in others, it needs an event hook to capture leaving timing from these specific applications (it could be Ctrl-Tab, mouse click, etc?) In addtion, the function must be triggered before leaving the app, I think it is not easy to do so...

[BlueDrink9]

I can confirm it isn't easy. I have a library for detecting a change in active window, but it doesn't exactly work flawlessly. We could integrate it, but I'd be concerned about how that would affect the stability of the rest of the application.

[rcmdnk]

@BlueDrink9 Thank you for the interesting library! If it works instantly, it may work by a function which switches back the app, resets caret, and goes back to the new app. If it can remember the caret width and triggers the function only when the caret is thick, the bad impact may be small. But I agree that we need to be carefully as it works every app change timing.