Spinner hijacks signals without option to override.

[graza-io]

Describe the bug
If I have custom signal capture behavior set up within my application, I want to be able to respect this even if I am running the spinner.

However, it seems that if the spinner is running, it hijacks my signal (exits the spinner without error) and pretends nothing has happened.

To Reproduce

Take this basic example, if while the spinner is running I hit ctrl+c it will exit with code 0 instead of the desired 123.

package main

import (
	"log/slog"
	"os"
	"os/signal"
	"time"

	"github.com/charmbracelet/huh/spinner"
)

func main() {
	sigChan := make(chan os.Signal, 1)
	signal.Notify(sigChan, os.Interrupt)
	go func() {
		<-sigChan
		slog.Debug("cancel handler got SIGINT")
		os.Exit(123)
	}()

	s := spinner.New()

	myFunc := func() {
		time.Sleep(1 * time.Hour)
	}

	err := s.Action(myFunc).Run()
	if err != nil {
		slog.Error("error", err)
	}
}

This is compounded if we move the spinner into a loop it can't break out of, as we'll never be able to exit.

package main

import (
	"log/slog"
	"os"
	"os/signal"
	"time"

	"github.com/charmbracelet/huh/spinner"
)

func main() {
	sigChan := make(chan os.Signal, 1)
	signal.Notify(sigChan, os.Interrupt)
	go func() {
		<-sigChan
		slog.Debug("cancel handler got SIGINT")
		os.Exit(123)
	}()

	s := spinner.New()

	myFunc := func() {
		time.Sleep(1 * time.Hour)
	}

	for {
		err := s.Action(myFunc).Run()
		if err != nil {
			slog.Error("error", err)
		}
	}
}

Expected behavior
Tea based applications take in ProgramOptions one of which is WithoutSignalHandler which would allow using our own SignalHandler logic instead of hijacking it.

In func (s *Spinner) Run() error you're passing some default ProgramOptions

p := tea.NewProgram(s, tea.WithContext(s.ctx), tea.WithOutput(os.Stderr))

Would be beneficial to allow optional passing of tea.WithoutSignalHandler() (as well as maybe some of the other options); allowing for a more usable spinner.

Desktop (please complete the following information):

• OS: macOS
• Version Sonoma 14.6.1

Additional context
Add any other context about the problem here.

[caarlos0]

it doesn't really hijack the signal, but it does hijack ctrl+c.

i believe the problem runs a bit deeper, even, we might need something like this: charmbracelet/bubbletea#1255

[camball]

Not sure if my issue is similar, but the following code hijacks my ctrl+c, and when entered, the input is cancelled, but the program continues to run with no error returned.

var value string

err := huh.NewInput().
	Title("Favourite colour?").
	Prompt("? ").
	Value(&value).
	Run()

if err != nil {
	return err
}

// continues running; `err` == `nil`

Tested an fmt.Scanln and ctrl+c worked properly. Been trying to figure out a solution for a bit now with not much luck.

[caarlos0]

both issues should be fixed by #491