nit: invert and early return

I've slightly changed the logic here. I just noticed it is slightly different to how the func (m selectModel) Update function works. m.search.Update can handle more than just a tea.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 it https://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 the textinput component also triggers the blinking behaviour

What happens if the program receives a kill -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 a coder command or cliui test binary? With coder I would expect the program to exit with a cancelled.

I used the cliui binary with go run ./cmd/cliui select. I shall try against the coder binary

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

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

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

The issue is, the event loop finishes on a QuitMsg command without notifying our Update 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 get err to contain the Canceled error.

I wrote a small signal handler

type terminateMsg struct{}

func installSignalHandler(p *tea.Program) chan struct{} {
	ch := make(chan struct{})

	go func() {
		sig := make(chan os.Signal, 1)
		signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)

		defer func() {
			signal.Stop(sig)
			close(ch)
		}()

		for {
			select {
			case <-ch:
				return

			case <-sig:
				p.Send(terminateMsg{})
			}
		}
	}()

	return ch
}

Then install it on a *tea.Program

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

And handle it in the Update methods

	switch msg := msg.(type) {
	case terminateMsg:
		m.canceled = true
		return m, 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 the coder 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 handle signal.Interrupt for the Windows compatibility.

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

Killing the process with kill -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.