W32 ime classic-n-experimental #12752
Conversation
Codecov Report
@@ Coverage Diff @@
## master #12752 +/- ##
==========================================
- Coverage 82.10% 81.41% -0.69%
==========================================
Files 160 160
Lines 193690 193773 +83
Branches 43492 43495 +3
==========================================
- Hits 159025 157762 -1263
- Misses 21819 23273 +1454
+ Partials 12846 12738 -108
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
The word "input method" has already different meaning, I think. It might be better to use another term. (Not sure what is the best term, though. "key event handling"?) |
Yes, "key event handling" would fit of course, with perhaps a little disadvantage of being too unspecific... How about - my personal favorite: "keyboard layout translation strategy" (strategy in a sense of design pattern "strategy") // shortened "kbdlayout_trans_strategy" Or perhaps: "keycode translation strategy" // shortened "keycode_trans_strategy" Yet another variant: "keyboard layout handling" // shortened "kbdlayout_handling" Let me know your preference to update PR accordingly. |
|
I checked the document of
I think "keycode translation strategy" is good. |
Word "strategy" is used in the code (inspired by "strategy" design pattern); in documentation it seem to be more appropriate to use the word "method" instead.
updated accordingly, please check |
|
I'm thinking if using |
Hm... Do we have such biest "gvim tiny version" at all ? Or it is perhaps issue with makefile for Mingw. I am using cross compiler with MINGW from linux - Make_cyg_ming.mak (with CROSS=yes), set "FEATURES=TINY" there, instead of "FEATURES=HUGE" and get bunch of errors when I try to build tiny gvim for windows, linking step fails [1]. Are there perhaps some good instructions how to build it otherwise? I quickly checked offline version of Tony's page but it is only talking about how to build unix flavors, nothing about cross-compile. (Well I can try later to build on another machine with cygwin mingw perhaps with more luck but... Will appreciate short advise to save time) [1] failure from linker on opensuse with cross-mingw for TINY version |
Is this just for now or are we going with some new option value? |
Hi @chrisbra , right now the plan is like this: |
|
Please ignore my comment about problems with TINY GVIM build (removing all *.o files manually solved my issue with it) Now the question is really, how to change the keycode_trans_strategy in TINY w32 GVIM. To introduce new normal option for that sounds somehow silly... In the beginning I was thinking we will check some environment variable once and do lazy initialize the strategy if it is not yet initialized - but that way we can only have one state per running instance, which cannot be changed on the fly, which quite restrict the possibilities for experimenting. Are there some similar "hidden developer back doors" existing, beside to let user to call some special function? |
|
In the meantime I will implement fallback check first time, if environment variable, let us say VIM_KEYCODE_TRANS_STRATEGY is defined, and if yes, it value (classic|experimental) will be used to initialize the strategy first time. So no dynamic change on the fly will be possible in TINY gvim. |
Quoting the docu:
Alternatively (this method is especially useful for the TINY GVIM build, where
test_mswin_event() cannot be called), environment variable
VIM_KEYCODE_TRANS_STRATEGY can be set to the desired value (`experimental' or
`classic'), to override default. E.g., type in dos prompt:
>
set VIM_KEYCODE_TRANS_STRATEGY=experimental
gvim.exe
<
|
I think there are some options:
I want to hear others' opinions. |
|
I have been wondering:
|
Kind of, especially on non-English keyboard layouts - with 'experimental' strategy one can start to map things, which are usually "overriden" by Examples
Also what puzzles me yet: it do not works to Another example:
Basically for Cyrillic layout seems that most russian letters with CTRL producing with 'classic' their underlying latin-key control codes (but strangely not like on German! - well this is a question to Microsoft and their TranslateMessage() implementation) and that is what users prefer to have restored back. However after more then one year of 'experimental' strategy being in the wild, we are never sure we break someone configuration by changing back to 'classic' - without supporting some migration possibility. Also I am not sure how 'classic' works with completely and completely non standard keyboard layouts like 'bepo' (https://en.wikipedia.org/wiki/B%C3%89PO) and if there more advantages on such layouts we have from 'experimental'. |
|
can we use the 'keyprotocol' option here? |
Signed-off-by: GuyBrush <miguel.barro@live.com>
Problem: win32: Ctrl-D cannot be used to close a pipe
Solution: Properly detect Ctrl-D when reading from a pipe
(GuyBrush)
Enabling Ctrl-D for gvim pipeline input
and apply defensive programming on account of PR #12752
so that once PR 12752 is merged, CTRL-D will keep on working
closes: #13849
Signed-off-by: GuyBrush <miguel.barro@live.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
To untangle complicated circumstances introduced in v8.2.4807 old way of interpreting keyboard input via TranslateMessage() is reverted to be default again. At the same time, new/experimental "input method" which is using ToUnicode() Win API call is still available, in case some users are already dependent on it. To change between both "input methods" in run-time testing events infrastructure is (mis?)used:
Documentation is updated accordingly.