subl causing dropped keystrokes

[JesseAldridge]

If I run subl from tview, after I finish editing the opened file and come back to the terminal my next keystroke seems to get dropped.

In the demo below I run the script, hit return to open sublime, close the text file, select the terminal, press return again (nothing happens), press return again (sublime opens again). I get similar behavior if I use subl -w instead of subl.

subl is configured like so: https://www.sublimetext.com/docs/3/osx_command_line.html

Any idea what the issue could be?

package main

import (
	"os"
	"os/exec"

	"github.com/gdamore/tcell"
	"github.com/rivo/tview"
)

func write_and_open(note_name string) {
	cmd := exec.Command("subl", note_name)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Run()
}

func main() {
	app := tview.NewApplication()

	app.SetInputCapture(func(event *tcell.EventKey) *tcell.EventKey {
		k := event.Key()
		if k == tcell.KeyEnter {
			app.Suspend(func() { write_and_open("test name") })
		}
		return event
	})

	box := tview.NewBox().SetBorder(true).SetTitle("Hello, world!")
	if err := app.SetRoot(box, true).Run(); err != nil {
		panic(err)
	}
}

[rivo]

This is a known issue in tcell, please see gdamore/tcell#194. You may want to add to that issue. I suspect that @gdamore will likely prioritize this higher if there are commercial incentives.

I'll close this issue here because I have no way of fixing this on my end.

[JesseAldridge]

commercial incentives

Are you saying I should offer him $100 to fix the bug or something?

[rivo]

Please discuss this with him.

None of this work pays and most of us have other, more important things to do. Personally, I will keep improving tview but I may be slow at times. Other package maintainers have different motivations and a different philosophy. As you know, many times, that philosophy is "I won't maintain this package anymore" (I have a number of previously very active packages in production wich have since been discontinued). A bugfix can sometimes require a whole lot of structural work which takes a lot of time. I can see how some maintainers will say "I can only spend that time for some kind of compensation" and if there's commercial interest on the other side (e.g. "our company needs this fixed"), maybe something can be worked out.

But again, I can't speak for @gdamore. This is just what I read in other threads.

[JesseAldridge]

One possibility might be to switch to wrapping a different terminal ui toolkit. Here is a list: http://repoq.com/lists/terminal_ui

I imagine that could be a lot of work. I have no idea how tied this thing is to tcell.

But depending on a project maintained by someone who is not very committed might not be the best idea.

Just a thought.

[gdamore]

It really comes down to time investment. But I love how you advise someone spending a bunch of their time to switch their rewrite their open source project on time you aren't paying for to satisfy your desires. As I said if you want to sponsor this work it's possible. Otherwise I'll get to it when I have time. Conversely if you want to do the work and submit a PR I have given some advice in the tcell issue. - Garrett

…

On Tue, Sep 11, 2018, 5:27 PM Jesse Aldridge ***@***.***> wrote: One possibility might be to switch to wrapping a different terminal ui toolkit. Here is a list: http://repoq.com/lists/terminal_ui I imagine that could be a lot of work. I have no idea how tied this thing is to tcell. But depending on a project maintained by someone who is not very committed might not be the best idea. Just a thought. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPDfSgYIOvzY3az236ziP39vvASIV1-ks5uaFT5gaJpZM4WiT2a> .

[JesseAldridge]

Heh, sorry dude. I didn't mean any offense. I do realize you aren't getting paid and have no obligation here.

[gdamore]

That's fine. For the record, of the repos you listed, all of the ones in golang other than tcell and termbox are implemented on top of either tcell or termbox. I'm not saying tcell is perfect here, but transitioning away from it would be hard, unless the project uses the termbox API. (tcell has a termbox API in the compat package to help with migration. termbox historically is really limited -- for example no 24-bit color, very limited capabilities with respect to extra key sequences, terminal types, mouse support on Windows, etc. etc. The reason I wrote tcell was to workaround limitations in termbox for some of my own projects.

Its kind of unfortunate that so many people are using this project, but of all my open source projects, tcell stands alone as one that is both very popular and one that has never generated a single penny of revenue, consulting leads, interviews, sponsorship, or anything of the like. Consequently my other projects, which do pay the bills tend to get more of my attention.

[rivo]

Just wanted to mention that tview is very tightly integrated with tcell. Even if it was simple to replace tcell (which it isn't), it would make tview completely backwards incompatible which I try to avoid very hard. I chose tcell because of the benefits @gdamore listed.

I completely understand his reasons to allocate his resources as he does. It's the same here. We all have to get used to a different speed in these projects. I just hope @gdamore will not abandon tcell, though. ;-)

[gdamore]

Thanks. I have no plans to abandon it. I am moving more towards a full time job rather than consulting starting next week. This may make it easier for me to work on other nonpaying projects on my own time but it probably also means that the total amount of time for all projects is going to be less. I tried to work on this last weekend but I was just too tired to get much done at the end of the weekend and too busy to work on it earlier. - Garrett

…

On Tue, Sep 25, 2018, 7:46 AM rivo ***@***.***> wrote: Just wanted to mention that tview is very tightly integrated with tcell. Even if it was simple to replace tcell (which it isn't), it would make tview completely backwards incompatible which I try to avoid very hard. I chose tcell because of the benefits @gdamore <https://github.com/gdamore> listed. I completely understand his reasons to allocate his resources as he does. It's the same here. We all have to get used to a different speed in these projects. I just hope @gdamore <https://github.com/gdamore> will not abandon tcell, though. ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPDfVyUAwgxYhEIg42kbLTf5yyZ8FWFks5uekHbgaJpZM4WiT2a> .

[thebsdbox]

For the time being the ugly hack I have is to drop a fake keypress..

import "github.com/micmonay/keybd_event"

// uiBugFix - This is used to fix the issue with tcell dropping a keystroke between new tcell.screens being created
// TODO (thebsdbox) remove this when tcell issue #194 is fixed
func uiBugFix() {
	kb, err := keybd_event.NewKeyBonding()
	if err != nil {
		return
	}
	//set keys
	kb.SetKeys(keybd_event.VK_SPACE)

	//launch
	kb.Launching()
}

[francop-eb]

Workaround this bug:

// This method avoid tcell bug https://github.com/gdamore/tcell/issues/194
// Aditional EOL event is sent to ensure, consequent events, are correctly handled
func sendExtraEventFix() {
	kb, err := keybd_event.NewKeyBonding()
	if err != nil {
		panic(err)
	}
	kb.SetKeys(keybd_event.VK_ENTER)
	err = kb.Launching()
	if err != nil {
		panic(err)
	}
}