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

gocui.KeyCtrlTilde doesn't seem to be triggering #76

Open
juliaschell opened this issue Jan 14, 2021 · 7 comments
Open

gocui.KeyCtrlTilde doesn't seem to be triggering #76

juliaschell opened this issue Jan 14, 2021 · 7 comments
Labels
bug Something isn't working

Comments

@juliaschell
Copy link

Anyone else had this issue? My keybinding for gocui.KeyCtrlTilde doesn't seem to be running

	if err := g.SetKeybinding("", gocui.KeyCtrlTilde, gocui.ModNone, ui.plan_move_week_quick_enter(rc, 1)); err != nil {
		return fmt.Errorf("Failed to set keybinding: %s", err)
	}
	if err := g.SetKeybinding("", gocui.KeyCtrl2, gocui.ModNone, ui.plan_move_week_quick_enter(rc, 2)); err != nil {
		return fmt.Errorf("Failed to set keybinding: %s", err)
	}


func (ui *PlanningUI) plan_move_week_quick_enter(rc *Radar, numForward int) func(g *gocui.Gui, v *gocui.View) error {
	return func(g *gocui.Gui, v *gocui.View) error {
		log.Debugf("Moving %d weeks forward",  numForward)
	}
}

When I hit ctrl+2, I get the log. when I hit ctrl+~, nothing happens.

@juliaschell juliaschell added the bug Something isn't working label Jan 14, 2021
@glvr182
Copy link
Member

glvr182 commented Jan 20, 2021

What version of gocui are you using?

@dankox
Copy link

dankox commented Jan 25, 2021

@glvr182 If she is using the newer version, the problem might be caused by this line:

KeyCtrlTilde = Key(tcell.KeyF64) // arbitrary assignment

It could be changed to have the same keybind as KeyCtrl2, which is tcell.KeyNUL, but the problem for me was, that I couldn't trigger that keybind at all. If you could try to debug it and put a breakpoint here:

k := tev.Key()

and maybe even on line 115 and check what key (or just what number) is obtained when such combination is hit, it would be good to see.

I was using linux machine thru ssh and was trying Windows Terminal and Hyper terminal (both windows versions) and I couldn't get it trigger anything. So I assume it doesn't have a key when using terminal on windows machine (even if logged to linux thru ssh).

If it doesn't trigger anything, maybe that key should be removed from the API. It was kept there for backward compatibility, but I can see that it might make more confusion than help.

@glvr182
Copy link
Member

glvr182 commented Jan 25, 2021

Ill do some testing this weekend, exams tomorrow and thursday 🙃. Thanks for pointing me in a direction to look for this!

@juliaschell
Copy link
Author

Was trying to use ctrl+~ because ctrl+1 is not available as an option. Why is this? BTW I'm on a Mac

@juliaschell
Copy link
Author

We have our own fork of your repo (forked to fix some text input issues I've mentioned in previous questions on here) so not really a specific version, but forked back in July. Last common commit is fa13102

@dankox
Copy link

dankox commented Jan 26, 2021

@juliaschell I see, so you are using older version with termbox library. That one has defined the key, so the above comment does not apply for you (about text wrapping, I think it might be resolved in the new beta version now).

As for why you can't see or use that key, your terminal probably does not have it mapped to anything. I don't think that key is actually mapped to something in general, as in termbox they have there mapping to /0 character, which represents also Ctrl+2 and maybe even some other keys. Lot of the key shortcuts might share the same ANSI sequence in terminal, like /t or Ctrl+I and so on. Ctrl+1 is "mapped" to 1 on mine so I guess that might be the reason why it wasn't included as it doesn't produce ANSI sequence with control key (only the regular key is represented).

You can try this command sed -n l and whatever key shortcut you type hit enter and after you should see what is the representation of it. I assume for the Ctrl+~ it would display only $ in the beginning of the line, which means that there is no ANSI sequence for it. The $ represents end of the line after the key sequence.
Also you could check infocmp -L1 to see sequences supported on your terminal.

In your case, I would probably go for F-keys, even though I know Mac doesn't have them easily accessible. Or go for some control and alphabet keys. But keep in mind they might produce same sequence as other keys, like Ctrl+M is the same as Enter and Ctrl+I is Tab.

@dankox
Copy link

dankox commented Jan 26, 2021

@glvr182 I think it's not necessary to debug as the problem is in the older version with termbox, but if you could try it might be worth to know if tcell actually produces something for Ctrl+~. I can't get it on my system, but who knows :)

Btw... if the Ctrl+~ really doesn't produce anything, I guess it might be worth to throw it away, so it doesn't confuse people and maybe document it. Or keep it for "backward" compatibility (to not cause compile errors), but definitely document it?
What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants