New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping backspace while typing Korean #1215

Closed
gerw opened this Issue Oct 31, 2016 · 34 comments

Comments

Projects
None yet
9 participants
@gerw

gerw commented Oct 31, 2016

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).

@chrisbra

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Nov 5, 2016

Member

why would you do something like this?

Member

chrisbra commented Nov 5, 2016

why would you do something like this?

@gerw

This comment has been minimized.

Show comment
Hide comment
@gerw

gerw Nov 5, 2016

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>.

gerw commented Nov 5, 2016

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>.

@chrisbra

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Nov 5, 2016

Member

can you provide a sample file with those glyphs?

Member

chrisbra commented Nov 5, 2016

can you provide a sample file with those glyphs?

@gerw

This comment has been minimized.

Show comment
Hide comment
@gerw

gerw Nov 5, 2016

What do you mean exactly? You can simply copy-and-paste these glyphs to vim.

gerw commented Nov 5, 2016

What do you mean exactly? You can simply copy-and-paste these glyphs to vim.

@chrisbra

This comment has been minimized.

Show comment
Hide comment
@chrisbra

chrisbra Nov 5, 2016

Member

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.

Member

chrisbra commented Nov 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Nov 5, 2016

Member

@Grew Which OS and IM/IME do you use? This kind of behavior is deeply related to input methods.

Member

k-takata commented Nov 5, 2016

@Grew Which OS and IM/IME do you use? This kind of behavior is deeply related to input methods.

@gerw

This comment has been minimized.

Show comment
Hide comment
@gerw

gerw Nov 5, 2016

In order to reproduce the behaviour, you actually have to type those characters. I used the instructions from vim-latex/vim-latex/issues/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?

gerw commented Nov 5, 2016

In order to reproduce the behaviour, you actually have to type those characters. I used the instructions from vim-latex/vim-latex/issues/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

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Nov 5, 2016

Member

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.

Member

k-takata commented Nov 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Feb 14, 2017

Member

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.

Member

k-takata commented Feb 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 26, 2017

@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 commented Aug 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 26, 2017

@brammool the patch provided from Yukihiro Nakadaira is working awesome for me. Please merge this.

mattn commented Aug 26, 2017

@brammool the patch provided from Yukihiro Nakadaira is working awesome for me. Please merge this.

@k-takata

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Aug 26, 2017

Member

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.

Member

k-takata commented Aug 26, 2017

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.

@brammool

This comment has been minimized.

Show comment
Hide comment
@brammool

brammool Aug 26, 2017

Contributor

@mattn with the patc from Yukihoro Nakadaira, do you mean the one that Ken Takata linked here?

Contributor

brammool commented Aug 26, 2017

@mattn with the patc from Yukihoro Nakadaira, do you mean the one that Ken Takata linked here?

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 27, 2017

mattn commented Aug 27, 2017

@tonymec

This comment has been minimized.

Show comment
Hide comment
@tonymec

tonymec Aug 27, 2017

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.

tonymec commented Aug 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@k-takata
Member

k-takata commented Aug 27, 2017

@tonymec

This comment has been minimized.

Show comment
Hide comment
@tonymec

tonymec Aug 27, 2017

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…

tonymec commented Aug 27, 2017

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…

@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Aug 27, 2017

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.

nuko8 commented Aug 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Aug 27, 2017

Member

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.

Member

k-takata commented Aug 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Aug 27, 2017

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.

nuko8 commented Aug 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 28, 2017

As far as I know (I'm user of UNIX XIM over 20years), this is over-the-spot.

mattn commented Aug 28, 2017

As far as I know (I'm user of UNIX XIM over 20years), this is over-the-spot.

@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Aug 28, 2017

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.

nuko8 commented Aug 28, 2017

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.

@brammool brammool closed this in 5c6dbcb Aug 30, 2017

@goweol

This comment has been minimized.

Show comment
Hide comment
@goweol

goweol Sep 18, 2017

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

goweol commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@k-takata

k-takata Sep 18, 2017

Member

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=""
Member

k-takata commented Sep 18, 2017

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=""
@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Sep 18, 2017

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:

  1. For GTK+ >= 3.20,
label#vim-gui-preedit-area {
    background-color: #ffffff;
    color: #000000;
}
  1. For GTK+ < 3.20,
GtkLabel#vim-gui-preedit-area {
    background-color: white;
    color: black;
}

Hopefully, either of them will do for you.

Kazunobu

nuko8 commented Sep 18, 2017

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:

  1. For GTK+ >= 3.20,
label#vim-gui-preedit-area {
    background-color: #ffffff;
    color: #000000;
}
  1. For GTK+ < 3.20,
GtkLabel#vim-gui-preedit-area {
    background-color: white;
    color: black;
}

Hopefully, either of them will do for you.

Kazunobu

@vim-ml

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml Sep 18, 2017

vim-ml commented Sep 18, 2017

@vim-ml

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml Sep 18, 2017

vim-ml commented Sep 18, 2017

@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Sep 18, 2017

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...

nuko8 commented Sep 18, 2017

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...

@nuko8

This comment has been minimized.

Show comment
Hide comment
@nuko8

nuko8 Sep 18, 2017

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?

nuko8 commented Sep 18, 2017

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-ml

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml Sep 18, 2017

vim-ml commented Sep 18, 2017

@vim-ml

This comment has been minimized.

Show comment
Hide comment
@vim-ml

vim-ml Sep 18, 2017

vim-ml commented Sep 18, 2017

adizero pushed a commit to adizero/vim that referenced this issue May 19, 2018

patch 8.0.1026: GTK on-the-spot input has problems
Problem:    GTK on-the-spot input has problems. (Gerd Wachsmuth)
Solution:   Support over-the-spot. (Yukihiro Nakadaira, Ketn Takata, closes
            #1215)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment