nit: invert and early return

I've slightly changed the logic here. I just noticed it is slightly different to how thefunc (m selectModel) Update function works.m.search.Update can handle more than just atea.KeyMsg. With the updated logic does this still make sense?

I found the blinking fairly distracting in the aciinemas, that behavior seemed different from the original. Is this what controls it and should we actually blink?

Yes, this is what controls ithttps://pkg.go.dev/github.com/charmbracelet/bubbles@v0.19.0/textinput#Blink.

I'm happy to back it out

Doing some more research, it appears that thetextinput component also triggers the blinking behaviour

What happens if the program receives akill -INT $PID while tea is active? Do we handle it nicely?

Unless I'm doing something wrong, it appears nothing happens?

Hmm, did you try with acoder command or cliui test binary? Withcoder I would expect the program to exit with a cancelled.

I used thecliui binary withgo run ./cmd/cliui select. I shall try against the coder binary

I checked onmain and this behaviour appears to be the status quo.

Just tested and it does not! Need to handle that then,err isnil

So... Bubbletea listens for SIGINT and SIGTERM signals and emits aQuitMsg command
https://github.com/charmbracelet/bubbletea/blob/e58efab3713e8f924e90a416e66326b23253f7ab/tea.go#L238-L272

The issue is, the event loop finishes on aQuitMsg command without notifying ourUpdate function.
https://github.com/charmbracelet/bubbletea/blob/e58efab3713e8f924e90a416e66326b23253f7ab/tea.go#L352-L355

We could potentially install our own signal handlers by disabling the builtin one
https://pkg.go.dev/github.com/charmbracelet/bubbletea#WithoutSignalHandler
https://github.com/charmbracelet/bubbletea/blob/e58efab3713e8f924e90a416e66326b23253f7ab/tea.go#L508-L511

I can confirm by disabling the builtin signal handler it is possible to geterr to contain theCanceled error.

I wrote a small signal handler

typeterminateMsgstruct{}funcinstallSignalHandler(p*tea.Program)chanstruct{} {ch:=make(chanstruct{})gofunc() {sig:=make(chan os.Signal,1)signal.Notify(sig,syscall.SIGINT,syscall.SIGTERM)deferfunc() {signal.Stop(sig)close(ch)}()for {select {case<-ch:returncase<-sig:p.Send(terminateMsg{})}}}()returnch}

Then install it on a*tea.Program

ch:=installSignalHandler(p)deferfunc() {ch<-struct{}{}}()

And handle it in theUpdate methods

switchmsg:=msg.(type) {caseterminateMsg:m.canceled=truereturnm,tea.Quit

If this seems okay I can push this change?@mafredri

Might I suggest returning a func instead of the channel for close/deregistering the handler? I feel the usage will be a bit more idiomatic/easy to understand.

On the other hand, perhaps we don't need to handle signals at all and leave it to be the responsibility of thecoder command that needs it? I guess it's possible the terminal is left in a bad state unless the signal is handled though (not sure if it enters raw mode or not).

PS. You might want to only handlesignal.Interrupt for the Windows compatibility.

Yes, definitely a good idea. Have made that change 👍

Killing the process withkill -TERM $PID leaves the cursor in a bad state if we don't explicitly handle it (syscall.SIGTERM).

Will push these changes up, can always revert if unhappy.