[GH-ISSUE #165] subl causing dropped keystrokes

kerem commented

2026-03-04 01:02:13 +03:00

Owner

Originally created by @JesseAldridge on GitHub (Sep 10, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/165

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

Originally created by @JesseAldridge on GitHub (Sep 10, 2018). Original GitHub issue: https://github.com/rivo/tview/issues/165 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) } } ```

kerem closed this issue

2026-03-04 01:02:14 +03:00

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@rivo commented on GitHub (Sep 11, 2018):

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.

@rivo commented on GitHub (Sep 11, 2018): 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.

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@JesseAldridge commented on GitHub (Sep 11, 2018):

commercial incentives

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

@JesseAldridge commented on GitHub (Sep 11, 2018): > commercial incentives Are you saying I should offer him $100 to fix the bug or something?

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@rivo commented on GitHub (Sep 11, 2018):

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.

@rivo commented on GitHub (Sep 11, 2018): 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.

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@JesseAldridge commented on GitHub (Sep 12, 2018):

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.

@JesseAldridge commented on GitHub (Sep 12, 2018): 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.

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@gdamore commented on GitHub (Sep 12, 2018):

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 notifications@github.com
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
https://github.com/rivo/tview/issues/165#issuecomment-420470616, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPDfSgYIOvzY3az236ziP39vvASIV1-ks5uaFT5gaJpZM4WiT2a
.

@gdamore commented on GitHub (Sep 12, 2018): 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 <notifications@github.com> 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 > <https://github.com/rivo/tview/issues/165#issuecomment-420470616>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABPDfSgYIOvzY3az236ziP39vvASIV1-ks5uaFT5gaJpZM4WiT2a> > . >

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@JesseAldridge commented on GitHub (Sep 12, 2018):

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

@JesseAldridge commented on GitHub (Sep 12, 2018): Heh, sorry dude. I didn't mean any offense. I do realize you aren't getting paid and have no obligation here.

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@gdamore commented on GitHub (Sep 12, 2018):

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.

@gdamore commented on GitHub (Sep 12, 2018): 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.

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@rivo commented on GitHub (Sep 25, 2018):

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

@rivo commented on GitHub (Sep 25, 2018): 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. ;-)

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@gdamore commented on GitHub (Sep 25, 2018):

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 notifications@github.com 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
https://github.com/rivo/tview/issues/165#issuecomment-424372942, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPDfVyUAwgxYhEIg42kbLTf5yyZ8FWFks5uekHbgaJpZM4WiT2a
.

@gdamore commented on GitHub (Sep 25, 2018): 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 <notifications@github.com> 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 > <https://github.com/rivo/tview/issues/165#issuecomment-424372942>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABPDfVyUAwgxYhEIg42kbLTf5yyZ8FWFks5uekHbgaJpZM4WiT2a> > . >

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@thebsdbox commented on GitHub (Feb 27, 2019):

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()
}

@thebsdbox commented on GitHub (Feb 27, 2019): 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() } ```

kerem commented

2026-03-04 01:02:15 +03:00

Author

Owner

@francop-eb commented on GitHub (Mar 30, 2019):

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

@francop-eb commented on GitHub (Mar 30, 2019): 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) } } ```

Rows
Columns

[GH-ISSUE #165] subl causing dropped keystrokes #131