[vim/vim] Mapping backspace while typing Korean (#1215)
Gerd Wachsmuth
I think there is a problem with mapping backspace in insert mode while typing Korean (maybe Japanese and Chinese behave similarly).
If I use Korean and type ghkd, I get 황 (which is composed of the characters ㅎㅗㅏㅇ). Now, if I use
:inoremap <bs> a<bs><bs>
everything still works as expected (an a is typed, and then the a and the previous character get deleted).
However, using
:let a="\<bs>"
:inoremap <bs> <c-r>=a<cr>
results in 호아. Somehow, the <c-r>= is not evaluated correctly while inserting multi-byte characters (via composition).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Christian Brabandt
why would you do something like this?
Gerd Wachsmuth
In the latex-suite, there is a smart-backspace feature which allows you to delete multiple characters at once (e.g., something like \"a which is an ordinary ä). This is implemented by mapping <bs> to <c-r>=SmartBackspaceFunction()<cr>.
Christian Brabandt
can you provide a sample file with those glyphs?
Gerd Wachsmuth
What do you mean exactly? You can simply copy-and-paste these glyphs to vim.
Christian Brabandt
I tried, but when I copied the mentioned glyph from your original post I got "'황' U+D669 Dec:54889 Hangul Syllable 황" Which is a single char and not composed of more characters. Using your provided inoremap function works and deletes the complete char. So I seems to be missing something here.
K.Takata
@grew Which OS and IM/IME do you use? This kind of behavior is deeply related to input methods.
Gerd Wachsmuth
In order to reproduce the behaviour, you actually have to type those characters. I used the instructions from vim-latex/vim-latex#67 to type these characters.
It appears that (while typing Korean), vim does something like the following:
You type the first character and vim enters a special mode (such that later characters can be melt into the first one). You type the second character and vim notices that it can be melt into the first one. Then, it removes the first one (by issuing a remappable backspace) and types the combined character. This procedure is interrupted by a mapped backspace.
@k-takata I reproduced the behaviour using Ubuntu with ibus-hangul. Is this what you need to know?
K.Takata
OK, currently Vim uses on-the-spot input style on GTK, but it is known that on-the-spot has some problems like you reported.
Using over-the-spot style instead of on-the-spot might solve the problem, and there was a patch for that: https://groups.google.com/forum/#!msg/vim_dev/SK3t_RsWMqM/K5Quc2PQftkJ
Unfortunately the patch was rejected because it just replaces on-the-spot with over-the-spot.
We need a patch which enables a user to select on-the-spot or over-the-spot.
K.Takata
We need a patch which enables a user to select on-the-spot or over-the-spot.
I have updated Yukihiro Nakadaira's patch to support this:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/63e9d7139a6626a9463f70b93ba484a7137437b0/gtk_im_over-the-spot.patch?fileviewer=file-view-default
If 'imstyle' is set to 0 (default), on-the-spot input style is used.
If 'imstyle' is set to 1, over-the-spot input style is used.
mattn
@brammool current implementation of :terminal is painful for XIM. Preediting string are not possible to be overlayed. For example, run TUI program on terminal and it show textbox, Vim must not change the textbox. So I suggest to change XIM style to over-the-spot. It should be default. Current implementation of preediting is broken. For example, preediting string is undo-able. It must not be undo-able.
mattn
@brammool the patch provided from Yukihiro Nakadaira is working awesome for me. Please merge this.
K.Takata
I have updated the over-the-spot patch:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/61ce17f3d84711e66282080eba0c995661a833cc/gtk_im_over-the-spot.patch?fileviewer=file-view-default
I changed the default to over-the-spot, because current on-the-spot style is broken.
Bram Moolenaar
@mattn with the patc from Yukihoro Nakadaira, do you mean the one that Ken Takata linked here?
mattn
On 8/27/17, Bram Moolenaar <notifi...@github.com> wrote:
> @mattn with the patc from Yukihoro Nakadaira, do you mean the one that Ken
> Takata linked here?
>
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/vim/vim/issues/1215#issuecomment-325161617
--
- Yasuhiro Matsumoto
Tony Mechelynck
According to the help, Vim supports OverTheSpot, OffTheSpot and Root but not OnTheSpot (see :help xim-input-style). Maybe some IM configuration is needed to avoid OnTheSpot?
Best regards,
Tony.
K.Takata
:help xim-input-style is outdated and needs an update for GTK.
My patch also includes the update to the help:
https://bitbucket.org/k_takata/vim-ktakata-mq/src/61ce17f3d84711e66282080eba0c995661a833cc/gtk_im_over-the-spot.patch?fileviewer=file-view-default#gtk_im_over-the-spot.patch-11
K.Takata
I have slightly updated the help of 'imstyle':
https://bitbucket.org/k_takata/vim-ktakata-mq/src/fecc7ae7fcb2b3c8ca9df3092c3343c355ca6455/gtk_im_over-the-spot.patch?at=default&fileviewer=file-view-default
Tony Mechelynck
I just noticed a typo in your addition to the help (at line 11 of the patch).
:help +GTK_GUI
E149: Sorry, no help for +GTK_GUI
:help +GUI_GTK
Aha! That's the correct tag…
K.Takata
Kazunobu Kuriyama
When input method styles are being talked about, people usually expect that they must be something mentioned in the input method protocol:
-
on-the-spot: The client application is directed by the IM Server to display all pre-edit data at the site of text insertion. The client registers callbacks invoked by the input method during pre-editing.
-
over-the-spot: The input method displays pre-edit data in a window which it brings up directly over the text insertion position.
The points would be "Who creates (or prepared) the window on which the process of conversion is preseented?" and "Who renders a series of characters on that?", rather than the difference in meaning between the prepositions, or impression or illustrative pictures imaged from them. Naturally, "at the site of text insertion" implies "on an application window which was already created by the application itself."
As to the proposed patch, IIUC, the client (= Vim) brings up a window for the IM, and follows directions from the IM as to what to draw there. In other words, although it calls itself OverTheSpot, it looks like an on-the-spot implementation on window creation in the sense that it is the client who creates a window where the process of conversion is to be displayed, and it looks much more like so as to who draws characters there.
In contrast to that, in the case of (protocol-compliant) over-the-spot, it's the IM who creates a window and draws a series of characters there, using geometric references provided by the client.
Probably, that might be something needs to be explained to stop people from confusing with the description of the patch. To me, it looks like on-the-spot-improved.
K.Takata
Here is a very good Japanese document which explains the four types of input styles with many screen shoots:
https://www.mozilla-japan.org/projects/intl/input-method-spec.html
(Actually this is a translation of English document, but I couldn't find the original English document.)
From the users point of view, the difference between the behavior of on-the-spot and over-the-spot style is obvious; the current behavior is on-the-spot and the behavior with my patch (with set imstyle=1) is over-the-spot. There's no confusion. For normal users how they are implemented is not important at all.
mattn
Kazunobu Kuriyama
Here is a very good Japanese document which explains the four types of input styles with many screen shoots: https://www.mozilla-japan.org/projects/intl/input-method-spec.html (Actually this is a translation of English document, but I couldn't find the original English document.)
Hmm, but your goal is to get your patch merged into the repo, isn't it? I'm wondering how the contents of that link could be persuasive to those who don't speak that language. AFAIK, the decision maker doesn't speak Japanese, and I remember once he wrote somewhere that he hand't used input method himself... If you follow this link, which I used to refer to the input method protocol, you find the authors of the protocol reference are Japanese. So I think you can make yourself understood better, too.
From the users point of view, the difference between the behavior of on-the-spot and over-the-spot style is obvious; the current behavior is on-the-spot and the behavior with my patch (with set imstyle=1) is over-the-spot. There's no confusion. For normal users how they are implemented is not important at all.
Yeah, that's true, but equally, to verify the patch rightly, the implementation desperately matters for devs. I simply wanted to point out that phrases like "OverTheSpot fixes the issue" wouldn't help people review the patch, because they would soon find that it was not over-the-spot. I thought avoiding such discrepancy would give a better result to the patch.
mattn
As far as I know (I'm user of UNIX XIM over 20years), this is over-the-spot.
Kazunobu Kuriyama
I follow the protocol specifications and do think that's a variant of on-the-spot, but that's not my point.
It's all about explanation.
If I were a member of your group, I would explain how the patch works like this:
The current OnTheSpot implementation offers a good UX by giving seamless look-and-feel to Vim and XIM. However, this means that, when XIM is under operation, user-defined key mappings are sent directly to XIM and often cause troubles like GitHub Issue #1215 since XIM isn't instructed what to do with such key mappings (and there's no way to instruct it).
To address problems like that, the patch gets Vim to newly create/show a pop-up window for the pre-edit area when XIM is activated. That way, while XIM is under operation, key events are intercepted from Vim and sent straight to XIM as they are, thereby eliminating the cause of the mentioned troubles.
Use of the pop-up window might give an impression that Vim's input method style downgrades to OverTheSpot. But that's not true. Since the pop-up window is created by Vim, it is under full control of it. Therefore, all the goodies the current OnTheSpot implementation offers, remain intact.
Disclaimer: I wrote the above only by skimming the patch and never looked into it in detail. To be honest, I don't know if it works like that. So I sincerely ask people to take it with a grain of salt.
Anyway, seems like I did something reviewers shouldn't do. To secure fairness, I'll refrain from giving further comments.
goweol
Hello,
I have a color problem with imstyle=1.
While I'm composing Hangul, the color is something like guifg=black, guibg=grey20. So that, I cannot see the character easily. I wanted to take screenshot, but it was not easy for composing window because when I try to take screenshot, composing is finished.
If I added lines below to the gtk-widgets.css, then color of the composing window is changed and I can see the character easily. But, this change has side-effect for other window.
- {
/* inherit the color from parent by default */
color: inherit;
background-color: @bg_color;
}
I used ubuntu-14.04 and Radiance theme. The gtk3.0 Radiance theme may have problem, but I tested several themes and they all show the same problem (same color).
Thanks,
namsh
K.Takata
Do you use fcitx? It added Vim in its blacklist because of the broken behavior before the patch.
If composing window is shown correctly when you execute Vim with vim -g, it is because of the blacklist.
To remove Vim from the blacklist, you can set the environment variable FCITX_NO_PREEDIT_APPS to empty.
To change it temporarily:
$ FCITX_NO_PREEDIT_APPS fcitx -r
$ gvim
To change system setting:
$ sudo vi /etc/environment
Then add the following line at the end of it:
FCITX_NO_PREEDIT_APPS=""
Kazunobu Kuriyama
namsh,
Long time no see ;)
If I added lines below to the gtk-widgets.css, then color of the composing window is changed and I can see the character easily. But, this change has side-effect for other window.
I guess "composing window" corresponds to what is called "preedit area" in our codebase (cf. src/mbyte.c). With this understanding, let me answer to your question.
The preedit area is a GtkLabel widget and has the name vim-gui-preedit-area. So, to confine color change to that widget, you can do:
- For GTK+ >= 3.20,
label#vim-gui-preedit-area { background-color: #ffffff; color: #000000; }
- For GTK+ < 3.20,
GtkLabel#vim-gui-preedit-area { background-color: white; color: black; }
Hopefully, either of them will do for you.
Kazunobu
vim-dev ML
> Do you use fcitx? It added Vim in its blacklist because of the broken
> behavior before the patch.
> If composing window is shown correctly when you execute Vim with |vim
> To remove Vim from the blacklist, you can set the environment variable
> |FCITX_NO_PREEDIT_APPS| to empty.
>
> To change it temporarily:
>
> |$ FCITX_NO_PREEDIT_APPS fcitx -r $ gvim |
>
> To change system setting:
>
> |$ sudo vi /etc/environment |
>
> Then add the following line at the end of it:
>
> |FCITX_NO_PREEDIT_APPS="" |
Well, I installed and used im-hangul when I used gtk2 version.
And now I use gtk3 version, I'm not sure that the im-hangul module is
used for gtk3. But, the im-hangul immodule for gtk3 is also installed
and I set 'GTK_IM_MODULE=hangul2' environment variable.
And I guess the immodule can set the color for the preedit area from
your statement. RIght? Then, I will try to change the immodule or check
the im-hangul source.
Thanks,
namsh
vim-dev ML
글:
> namsh,
>
> Long time no see ;)
>
> If I added lines below to the gtk-widgets.css, then color of the
> composing window is changed and I can see the character easily. But,
> this change has side-effect for other window.
>
> I guess "composing window" corresponds to what is called "preedit area"
>
> The preedit area is a GtkLabel widget and has the name
> can do:
>
> 1. For GTK+ >= 3.20,
>
> label#vim-gui-preedit-area {
> background-color:#ffffff;
> color:#000000;
> }
>
>
> GtkLabel#vim-gui-preedit-area {
> background-color:white;
> color:black;
> }
>
> Hopefully, either of them will do for you.
you suggested. And there was no change for color of the preedit area. :(
Kazunobu Kuriyama
Though the ubuntu-14.04 has gtk+ 3.10.8, I tried to add both settings you suggested. And there was no change for color of the preedit area. :(
Too bad... GTK+ CSS had long been unstable and subject to subtle but backward incompatible changes until 3.20. Those version differences are a headache to everybody.
As far as I can tell, there's no comprehensive user guide on GTK+ CSS. People need to search for necessary documents for themselves, and what is worse, they were written mainly for developers.
As to 3.10.8, you would find a relatively detailed explanation on selectors here (Please scroll down and find the section "Selectors." Don't close it at first glance :). For the file format, this might be helpful.
Hmm, skimming those docs, I got a feeling that the selector GtkLabel#vim-gui-preedit-area was correct even for 3.10.8. But I'm not sure what's wrong with it...
—
You are receiving this because you commented.
Kazunobu Kuriyama
BTW, honestly, I've never used a file called gtk-widgets.css. If you put the code snippet in your $HOME/.config/gtk-3.0/gtk.css instead of that file, will it make a difference?
vim-dev ML
글:
> BTW, honestly, I've never used a file called |gtk-widgets.css|. If you
> that file, will it make a difference?
GtkLabel#vim-gui-preedit-area {
background-color: #ffffff;
color: #000000;
}
But, adding below does change the color for preedit area.
GtkWidget {
background-color: #ffffff;
color: #000000;
}
I tried to change the input method to ibus or xim via im-config or
GTK_IM_HANGUL env. var. But, gvim-gtk3 always tried to use imhangul.
I confirmed that gvim-gtk3 uses imhangul by removing the im-hangul.so.
Now, I did googling how I can change the input method for gtk3.
Thanks,
namsh
—
You are receiving this because you are subscribed to this thread.
vim-dev ML
> 2017-09-18 오후 3:15에 Kazunobu Kuriyama (Vim Github Repository) 이(가) 쓴
> 글:
> > BTW, honestly, I've never used a file called |gtk-widgets.css|. If you
> > put the code snippet in your |$HOME/.config/gtk-3.0/gtk.css| instead of
> > that file, will it make a difference?
>
> Adding below to gtk.css does not change the color.
>
> GtkLabel#vim-gui-preedit-area {
> background-color: #ffffff;
> color: #000000;
> }
>
> But, adding below does change the color for preedit area.
>
> GtkWidget {
> background-color: #ffffff;
> color: #000000;
> }
>
> I tried to change the input method to ibus or xim via im-config or
> GTK_IM_HANGUL env. var. But, gvim-gtk3 always tried to use imhangul.
> I confirmed that gvim-gtk3 uses imhangul by removing the im-hangul.so.
> Now, I did googling how I can change the input method for gtk3.
immodule. So that, I try to download imhangul 3.1.1 source and build it
myself.
And now it shows different color for preedit area (bg=white, fg=red).
The installed version of imhangul is alwo 3.1.1. I just compiled vanilla
source and just copied the im-hangul.so to the system folder.
My plan was to change the source to see if imhangul is related to this
problem. But... ubuntu may apply some patch to the imhangul-3.1.1?
Well, now I will stop further investigating. Will just use my built
version of imhangul.
But, if you want me to do something, please let me know.