[GH-ISSUE #210] App exit after zooming out #117

Closed
opened 2026-03-03 16:22:30 +03:00 by kerem · 8 comments
Owner

Originally created by @keithknott26 on GitHub (May 21, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/210

Originally assigned to: @keithknott26 on GitHub.

@mum4k ,

After changing termdash to use key.keyboardEsc to quit the app, I noticed that when the app is left running for a long time (5+ hours) you can exit out of it by zooming into the linechart and quickly zooming out. I've tested this using the standard trackpad for my Macbook and noticed that when the application exits there is no panic, I do see a large number of escape characters printed to the screen, and my terminal stays in alternate screen mode. Scrolling up or down on the trackpad after the application exists, results in printing the escape characters to the screen. The only way to restore the terminal functionality is to type reset.

Could this be a bug in termdash? I've attached a screenshot of the output once the app exits. Since I can replicate this very easily, I'm hoping you might be able to recommend if I should place some debug lines in strategic locations, log to a file locally, or if providing the output of kill -ABRT is sufficient to debug this.

Exiting Dashboard...
^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M____________________
Originally created by @keithknott26 on GitHub (May 21, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/210 Originally assigned to: @keithknott26 on GitHub. @mum4k , After changing termdash to use key.keyboardEsc to quit the app, I noticed that when the app is left running for a long time (5+ hours) you can exit out of it by zooming into the linechart and quickly zooming out. I've tested this using the standard trackpad for my Macbook and noticed that when the application exits there is no panic, I do see a large number of escape characters printed to the screen, and my terminal stays in alternate screen mode. Scrolling up or down on the trackpad after the application exists, results in printing the escape characters to the screen. The only way to restore the terminal functionality is to type reset. Could this be a bug in termdash? I've attached a screenshot of the output once the app exits. Since I can replicate this very easily, I'm hoping you might be able to recommend if I should place some debug lines in strategic locations, log to a file locally, or if providing the output of kill -ABRT is sufficient to debug this. ``` Exiting Dashboard... ^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M^[[<65;81;17M____________________ ```
kerem 2026-03-03 16:22:30 +03:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@mum4k commented on GitHub (May 21, 2019):

Hey @keithknott26,

thanks for reporting this. It might be that termdash (or termbox) incorrectly interprets one of the mouse events as the Esc key. But something else could be happening also, we should investigate this.

One important question is - does this only happen after running for 5+ hours? Or can you reproduce it without the long run. If it only happens after running for a long time, it might indicate a leak somewhere in the event distribution system.

To confirm the theory that a mouse event is interpreted as an Esc key, we would modify the demo. We could register a custom mouse subscriber and modify the custom keyboard subscriber so that they write all received events to a buffer for later investigation. The registration:

github.com/mum4k/termdash@b60c1c5fb0/termdash.go (L74-L90)

Example of the new mouse and modified keyboard subscribers is below. Note that this probably contains some errors / typos as I didn't test it.

// In global scope of the demo package.
var buff bytes.Buffer

func main {
  mouseRecorder := func(m *terminalapi.Mouse) {
    buff.WriteString(fmt.Sprintf("got mouse event with button: %v\n", m.Button))
  }
  quitter := func(k *terminalapi.Keyboard) {
    buff.WriteString(fmt.Sprintf("got keyboard event with key: %v (%d) rune: %c\n", k.Key, k.Key, k.Key))
    if k.Key == keyboard.KeyEsc || k.Key == keyboard.KeyCtrlC {
      // Quitting so save the buffer to a file.
      ioutil.WriteFile("/tmp/eventlog.txt", []byte{buff.String()}, 0644)
      cancel()
    }
  }
  if err := termdash.Run(ctx, t, c,
    termdash.KeyboardSubscriber(quitter),
    termdash.MouseSubscriber(mouseRecorder),
    termdash.RedrawInterval(redrawInterval),
  ); err != nil {
    panic(err)
  }
}

Feel free to adjust what is logged so that we have all the needed information. Is this something you could try out?

Please let me know if you would prefer I put this together in some separate branch and share the code with you instead.

<!-- gh-comment-id:494601294 --> @mum4k commented on GitHub (May 21, 2019): Hey @keithknott26, thanks for reporting this. It might be that termdash (or termbox) incorrectly interprets one of the mouse events as the Esc key. But something else could be happening also, we should investigate this. One important question is - does this **only** happen after running for 5+ hours? Or can you reproduce it without the long run. If it only happens after running for a long time, it might indicate a leak somewhere in the event distribution system. To confirm the theory that a mouse event is interpreted as an Esc key, we would modify the demo. We could register a custom mouse subscriber and modify the custom keyboard subscriber so that they write all received events to a buffer for later investigation. The registration: https://github.com/mum4k/termdash/blob/b60c1c5fb019886cd945a537586b315831a1c03c/termdash.go#L74-L90 Example of the new mouse and modified keyboard subscribers is below. Note that this probably contains some errors / typos as I didn't test it. ```go // In global scope of the demo package. var buff bytes.Buffer func main { mouseRecorder := func(m *terminalapi.Mouse) { buff.WriteString(fmt.Sprintf("got mouse event with button: %v\n", m.Button)) } quitter := func(k *terminalapi.Keyboard) { buff.WriteString(fmt.Sprintf("got keyboard event with key: %v (%d) rune: %c\n", k.Key, k.Key, k.Key)) if k.Key == keyboard.KeyEsc || k.Key == keyboard.KeyCtrlC { // Quitting so save the buffer to a file. ioutil.WriteFile("/tmp/eventlog.txt", []byte{buff.String()}, 0644) cancel() } } if err := termdash.Run(ctx, t, c, termdash.KeyboardSubscriber(quitter), termdash.MouseSubscriber(mouseRecorder), termdash.RedrawInterval(redrawInterval), ); err != nil { panic(err) } } ``` Feel free to adjust what is logged so that we have all the needed information. Is this something you could try out? Please let me know if you would prefer I put this together in some separate branch and share the code with you instead.
Author
Owner

@keithknott26 commented on GitHub (Jun 6, 2019):

How would you go about fixing this piece, the complier doesn't like this line

ioutil.WriteFile("/tmp/eventlog.txt", []byte{buff.String()}, 0644)

"Cannot use buff.String() as type byte in array or slice literal"

I can reproduce this fairly easily the app just needs some soak time. I noticed it happens when you scroll up or down very fast after the app has been lagging doing a bunch of work for a few hours.

**Edit, nevermind I see it.. it needs ()'s instead of {}'s. Should have the log back shortly.

<!-- gh-comment-id:499369916 --> @keithknott26 commented on GitHub (Jun 6, 2019): How would you go about fixing this piece, the complier doesn't like this line `ioutil.WriteFile("/tmp/eventlog.txt", []byte{buff.String()}, 0644)` "Cannot use buff.String() as type byte in array or slice literal" I can reproduce this fairly easily the app just needs some soak time. I noticed it happens when you scroll up or down very fast after the app has been lagging doing a bunch of work for a few hours. **Edit, nevermind I see it.. it needs ()'s instead of {}'s. Should have the log back shortly.
Author
Owner

@keithknott26 commented on GitHub (Jun 6, 2019):

Let me know if this helps or if you'd like me to try another approach to capture the necessary debug logging.

| => cat /tmp/eventlog.txt
got mouse event with button: ButtonLeft
got mouse event with button: ButtonLeft
got mouse event with button: ButtonRelease
got mouse event with button: ButtonLeft
got mouse event with button: ButtonLeft
got mouse event with button: ButtonRelease
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got keyboard event with key: 5 (53) rune: 5
got keyboard event with key: 5 (53) rune: 5
got keyboard event with key: 3 (51) rune: 3
got keyboard event with key: KeyEsc (-50) rune: �

Another attempt resulted in the following (note i didn't hit ESC)

got keyboard event with key: KeyEsc (-50) rune: �

And another attempt

got mouse event with button: ButtonLeft
got mouse event with button: ButtonLeft
got mouse event with button: ButtonRelease
got mouse event with button: ButtonLeft
got mouse event with button: ButtonLeft
got mouse event with button: ButtonRelease
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelDown
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got keyboard event with key: 5 (53) rune: 5
got keyboard event with key: 5 (53) rune: 5
got keyboard event with key: 3 (51) rune: 3
got keyboard event with key: KeyEsc (-50) rune: �

Seems to be easier to replicate this on a machine that's under load and responding slowly. Also I noticed that I actually don't need to wait 5 hours, I can replicate it right away by quickly scrolling up and down on the standard OSX trackpad, and a standard USB mouse with scrollwheel.

Here is some other stuff I thought might help:

Terminal.App for OSX 10.14.5
Standard "Basic" Theme , SF Mono Regular 11 font
echo $TERM;
xterm-256color

Scroll Alternate screen [x] enabled
Delete sends Control-H [ ] disabled
Escape non-ASCII input with Control-V [ ] disabled
Paste newlines as carriage returns. [x] enabled
Allow VT100 application keypad mode. [x] enabled
Scroll to bottom on input. [x] enabled
Text Encoding: UTF-8

<!-- gh-comment-id:499376181 --> @keithknott26 commented on GitHub (Jun 6, 2019): Let me know if this helps or if you'd like me to try another approach to capture the necessary debug logging. ``` | => cat /tmp/eventlog.txt got mouse event with button: ButtonLeft got mouse event with button: ButtonLeft got mouse event with button: ButtonRelease got mouse event with button: ButtonLeft got mouse event with button: ButtonLeft got mouse event with button: ButtonRelease got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got keyboard event with key: 5 (53) rune: 5 got keyboard event with key: 5 (53) rune: 5 got keyboard event with key: 3 (51) rune: 3 got keyboard event with key: KeyEsc (-50) rune: � ``` Another attempt resulted in the following (note i didn't hit ESC) `got keyboard event with key: KeyEsc (-50) rune: �` And another attempt ``` got mouse event with button: ButtonLeft got mouse event with button: ButtonLeft got mouse event with button: ButtonRelease got mouse event with button: ButtonLeft got mouse event with button: ButtonLeft got mouse event with button: ButtonRelease got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelDown got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got keyboard event with key: 5 (53) rune: 5 got keyboard event with key: 5 (53) rune: 5 got keyboard event with key: 3 (51) rune: 3 got keyboard event with key: KeyEsc (-50) rune: � ``` Seems to be easier to replicate this on a machine that's under load and responding slowly. Also I noticed that I actually don't need to wait 5 hours, I can replicate it right away by quickly scrolling up and down on the standard OSX trackpad, and a standard USB mouse with scrollwheel. Here is some other stuff I thought might help: Terminal.App for OSX 10.14.5 Standard "Basic" Theme , SF Mono Regular 11 font echo $TERM; xterm-256color Scroll Alternate screen [x] enabled Delete sends Control-H [ ] disabled Escape non-ASCII input with Control-V [ ] disabled Paste newlines as carriage returns. [x] enabled Allow VT100 application keypad mode. [x] enabled Scroll to bottom on input. [x] enabled Text Encoding: UTF-8
Author
Owner

@mum4k commented on GitHub (Jun 6, 2019):

Thanks a lot Keith.Sorry, the ioutil error was actually my typo, it should have been:

ioutil.WriteFile("/tmp/eventlog.txt", []byte(buff.String()), 0644)

Notice the regular parenthesis (i.e. type conversion) as opposed to the curly ones (i.e. type literal creation).

<!-- gh-comment-id:499637522 --> @mum4k commented on GitHub (Jun 6, 2019): Thanks a lot Keith.Sorry, the ioutil error was actually my typo, it should have been: ```go ioutil.WriteFile("/tmp/eventlog.txt", []byte(buff.String()), 0644) ``` Notice the regular parenthesis (i.e. type conversion) as opposed to the curly ones (i.e. type literal creation).
Author
Owner

@mum4k commented on GitHub (Jun 6, 2019):

So it looks like Termdash actually gets the keyboard Esc events. The next step would be to figure out if this is a bug in Termdash or upstream.

We should move the logging up to where Termdash pulls terminal events out of Termbox, i.e. here:
github.com/mum4k/termdash@68bf0566e6/terminal/termbox/termbox.go (L142)

We probably want to log the output of tbx.PollEvent() into a file.

  • If the Escape key comes from here - this will be either bug in the Terminal.App (or related to its configuration) or a bug in Termbox.
  • If we don't see the Escape event here, but do see it down in the widget (I would recommend logging in both locations for comparison), this is a but in Termdash.

Do note that we might need to be creative in how we log the output of tbx.PollEvent(), since the Termbox Event type doesn't implement fmt.Stringer. So we might need to print them as:

fmt.Fprintf(&buff, "Termbox event: %+v (%#v)", ev, ev)

Let me know what you think about this approach.
<!-- gh-comment-id:499639698 --> @mum4k commented on GitHub (Jun 6, 2019): So it looks like Termdash actually gets the keyboard Esc events. The next step would be to figure out if this is a bug in Termdash or upstream. We should move the logging up to where Termdash pulls terminal events out of Termbox, i.e. here: https://github.com/mum4k/termdash/blob/68bf0566e6ec8effaf6e83400ef0046347a5f5f1/terminal/termbox/termbox.go#L142 We probably want to log the output of `tbx.PollEvent()` into a file. - If the Escape key comes from here - this will be either bug in the Terminal.App (or related to its configuration) or a bug in Termbox. - If we don't see the Escape event here, but do see it down in the widget (I would recommend logging in both locations for comparison), this is a but in Termdash. Do note that we might need to be creative in how we log the output of `tbx.PollEvent()`, since the Termbox `Event` type doesn't implement fmt.Stringer. So we might need to print them as: ```go fmt.Fprintf(&buff, "Termbox event: %+v (%#v)", ev, ev) Let me know what you think about this approach. ```
Author
Owner

@keithknott26 commented on GitHub (Jun 6, 2019):

Jakub,

I took your suggestion and moved the logging up to termbox.go, I was able to capture the events which lead up to the application exit and have included them below. It looks like scrolling up / down results in some variation of 'KeyEsc[<6' or 'KeyEsc[<' 'KeyEsc<64;' or 'KeyEsc<64;6' depending on which direction I'm going on the Macbook Pro trackpad. Could the event system be aware of these key combinations and ensure they're always taken in chunks instead of interpreted individually somehow?

I should mention I can replicate this on two different terminal programs, Terminal.App and iTerm2

The widget gets this:

got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got mouse event with button: ButtonWheelUp
got keyboard event with key: KeyEsc (-50) rune: �

Termbox.Go Gets:

Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5})
Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5})
Termbox event: Keyboard{Key: KeyEsc} (&terminalapi.Keyboard{Key:-50})
Termbox event: Keyboard{Key: [} (&terminalapi.Keyboard{Key:91})
Termbox event: Keyboard{Key: <} (&terminalapi.Keyboard{Key:60})
Termbox event: Keyboard{Key: 6} (&terminalapi.Keyboard{Key:54})
Termbox event: Keyboard{Key: 5} (&terminalapi.Keyboard{Key:53})
Termbox event: Keyboard{Key: ;} (&terminalapi.Keyboard{Key:59})
Termbox event: Keyboard{Key: 7} (&terminalapi.Keyboard{Key:55})
Termbox event: Keyboard{Key: 3} (&terminalapi.Keyboard{Key:51})
Termbox event: Keyboard{Key: ;} (&terminalapi.Keyboard{Key:59})
<!-- gh-comment-id:499679418 --> @keithknott26 commented on GitHub (Jun 6, 2019): Jakub, I took your suggestion and moved the logging up to termbox.go, I was able to capture the events which lead up to the application exit and have included them below. It looks like scrolling up / down results in some variation of 'KeyEsc[<6' or 'KeyEsc[<' 'KeyEsc<64;' or 'KeyEsc<64;6' depending on which direction I'm going on the Macbook Pro trackpad. Could the event system be aware of these key combinations and ensure they're always taken in chunks instead of interpreted individually somehow? I should mention I can replicate this on two different terminal programs, Terminal.App and iTerm2 The widget gets this: ``` got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got mouse event with button: ButtonWheelUp got keyboard event with key: KeyEsc (-50) rune: � ``` Termbox.Go Gets: ``` Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelDown} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:6}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5}) Termbox event: Mouse{Position: (72,13), Button: ButtonWheelUp} (&terminalapi.Mouse{Position:image.Point{X:72, Y:13}, Button:5}) Termbox event: Keyboard{Key: KeyEsc} (&terminalapi.Keyboard{Key:-50}) Termbox event: Keyboard{Key: [} (&terminalapi.Keyboard{Key:91}) Termbox event: Keyboard{Key: <} (&terminalapi.Keyboard{Key:60}) Termbox event: Keyboard{Key: 6} (&terminalapi.Keyboard{Key:54}) Termbox event: Keyboard{Key: 5} (&terminalapi.Keyboard{Key:53}) Termbox event: Keyboard{Key: ;} (&terminalapi.Keyboard{Key:59}) Termbox event: Keyboard{Key: 7} (&terminalapi.Keyboard{Key:55}) Termbox event: Keyboard{Key: 3} (&terminalapi.Keyboard{Key:51}) Termbox event: Keyboard{Key: ;} (&terminalapi.Keyboard{Key:59}) ``` <application exits here>
Author
Owner

@mum4k commented on GitHub (Jun 7, 2019):

Thanks again @keithknott26, it is good to have a confirmation that these are legitimate events coming from the terminal.

Before we look for workarounds like event combining or preprocessing, it might be a good idea to get a better understanding of why this is happening. Assuming that you still have some time to dig deeper, here are a couple of questions worth investigating:

  • Does this only happen in the native terminal app? Can we try in other terminals like iTerm?
  • Does it happen only on the trackpad? Or also when using mouse?
  • Might it be related to some Apple gesture that we are accidentally triggering? Zoom in/out? Anything else?
  • Can we try to find (google / documentation / etc) any mention of this specific sequence of keys and what it is supposed to mean on the terminal?

Feel free to suggest anything else that comes to mind.

<!-- gh-comment-id:499727738 --> @mum4k commented on GitHub (Jun 7, 2019): Thanks again @keithknott26, it is good to have a confirmation that these are legitimate events coming from the terminal. Before we look for workarounds like event combining or preprocessing, it might be a good idea to get a better understanding of why this is happening. Assuming that you still have some time to dig deeper, here are a couple of questions worth investigating: - Does this only happen in the native terminal app? Can we try in other terminals like iTerm? - Does it happen only on the trackpad? Or also when using mouse? - Might it be related to some Apple gesture that we are accidentally triggering? Zoom in/out? Anything else? - Can we try to find (google / documentation / etc) any mention of this specific sequence of keys and what it is supposed to mean on the terminal? Feel free to suggest anything else that comes to mind.
Author
Owner

@mum4k commented on GitHub (Mar 7, 2020):

Closing as obsolete, please reopen if this still needs attention.

<!-- gh-comment-id:596094661 --> @mum4k commented on GitHub (Mar 7, 2020): Closing as obsolete, please reopen if this still needs attention.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/termdash#117
No description provided.