Navigation Menu

Skip to content
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

Can't type a backtick/tilde `/~ on Linux #7

Closed
tv42 opened this issue Sep 28, 2018 · 7 comments
Closed

Can't type a backtick/tilde `/~ on Linux #7

tv42 opened this issue Sep 28, 2018 · 7 comments

Comments

@tv42
Copy link

tv42 commented Sep 28, 2018

I can type with most keys fine but the key on the upper left under escape (US qwerty) that produces backtick and tilde does nothing. Ubuntu Linux, nothing really weird done with that part of my keyboard settings.

@jmigpin
Copy link
Owner

jmigpin commented Sep 28, 2018

Does it work if you '~' followed by 'space'? The next stroke decides if it adds a '~' or for example 'ã','ẽ', ...

@tv42
Copy link
Author

tv42 commented Sep 28, 2018

Oh, yes, it seems to act as if preceded by the compose key.

@jmigpin
Copy link
Owner

jmigpin commented Sep 28, 2018

I'm not sure how to detect if a user setup uses a compose key and has keys like tilde be printed directly.

Leaving here the reference where the current behavior is implemented.

isLatch := event.ComposeDiacritic(&evt.KeySym, &evt.Rune)

@tv42
Copy link
Author

tv42 commented Sep 28, 2018

So apparently there's an implementation of something in Xlib (which XCB/xgb don't use), and then all the GUI frameworks like GTK/Qt implement something. What a mess.

For what it's worth, this patch seems to make it behave like your average US keyboard user would expect (except that compose key inserts some literal character, doesn't compose):

diff --git i/util/uiutil/widget/applyevent.go w/util/uiutil/widget/applyevent.go
index cbd7de1..926b145 100644
--- i/util/uiutil/widget/applyevent.go
+++ w/util/uiutil/widget/applyevent.go
@@ -40,10 +40,7 @@ func (ae *ApplyEvent) Apply(node Node, ev interface{}, p image.Point) {
                // mouseup can cause a ui change, enter/leave needs to run
                ae.mouseEnterLeave(node, p)
        case *event.KeyDown:
-               isLatch := event.ComposeDiacritic(&evt.KeySym, &evt.Rune)
-               if !isLatch {
-                       ae.depthFirstEv(node, evt, p)
-               }
+               ae.depthFirstEv(node, evt, p)
        default:
                // ex: event.KeyUp
                ae.depthFirstEv(node, evt, p)

@jmigpin
Copy link
Owner

jmigpin commented Sep 28, 2018

Yes, I suspected that was your use case. Need to investigate this further.

jmigpin added a commit that referenced this issue Oct 1, 2018
event: Separate diacritics code into new file.
@jmigpin
Copy link
Owner

jmigpin commented Oct 1, 2018

@tv42 I hope the compose key is now correctly detected if you use the "usemultikey" cmd line option. I don't have a way to completely test this here so appreciate your feedback.

It would either be this or implement something like you mentioned that could include reading config files.

@jmigpin
Copy link
Owner

jmigpin commented Nov 10, 2018

So I was able to test this (simulate a US keyboard) with:
setxkbmap -rules evdev -model hpi6 -layout us -option "compose:caps"

Running the editor with the --usemultikey option, I was able to do the following:

  • pressing ~ outputs immediatley the rune
  • pressing the multikey (my case was caps-lock) allows composition: caps, ~, a outputs ã

Going to consider that this was fixed by b6828a7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants