WithoutSignalHandler()

[JetSetIlly]

Describe the bug

WithoutSignalHandler() doesn't work as I would expect

Setup

go 1.24.0
bubbletea 1.3.4
xterm

To Reproduce

With reference to the program below, the first ctrl-c press is correctly received by the channel set up with signal.Notify().

Once the bubbletea loop starts, pressing keys causes the message to change. Pressing the r key however causes the program to wait for another ctrl-c press. However, the program never receives the ctrl-c press over the previously established channel

The choice of r key isn't part of the problem. It's just a way of getting the loop to pause and wait for a signal.

Source Code

package main

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"

	tea "github.com/charmbracelet/bubbletea"
)

type model struct {
	sig     chan os.Signal
	message string
}

func (m *model) Init() tea.Cmd {
	return nil
}

func (m *model) View() string {
	return m.message
}

func (m *model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.String() {
		case "r":
			fmt.Println("press ctrl-c to resume")
			<-m.sig
			m.message = "completed"
		default:
			m.message = fmt.Sprintf("%s pressed", msg.String())
		}
	}
	return m, nil
}

func main() {
	m := &model{
		sig:     make(chan os.Signal, 1),
		message: "press a key",
	}

	signal.Notify(m.sig, syscall.SIGINT)
	fmt.Println("press ctrl-c to start")
	<-m.sig

	p := tea.NewProgram(m, tea.WithoutSignalHandler())
	p.Run()
}

Expected behavior

When WithoutSignalHandler() has been used as an option to NewProgram() then I would expect the SIGINT to be sent over the sig channel after the bubbletea loop has started.

[desertwitch]

I am not sure if that's not exactly the way it was intended, WithoutSignalHandler() effectively has all of the magic combinations treated as regular text input - which Update() can then parse. However, if you deadlock your Update() function waiting for a signal that never arrives, you can't ever proceed in your program - with anything.

func (m *model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.String() {
		case "ctrl+c":
			fmt.Println("ctrl+c pressed")
		default:
			m.message = fmt.Sprintf("%s pressed", msg.String())
		}
	}
	return m, nil
}

desertwitch@vDebianDev:~/bubbletea-ext$ go run .
ctrl+c pressed

So either you need to propagate the signal down to the main routine (not using WithoutSignalHandler()), if you want it handled there, or parse the magic combinations as regular KeyMsg input in Update() BUT without deadlocking Update(). The latter would mean not waiting on a signal channel and just calling your logic when the magic combinations were regularly detected as KeyMsg.

[JetSetIlly]

So either you need to propagate the signal down to the main routine (not using WithoutSignalHandler()), if you want it handled there, or parse the magic combinations as regular KeyMsg input in Update() BUT without deadlocking Update(). The latter would mean not waiting on a signal channel and just calling your logic when the magic combinations were regularly detected as KeyMsg.

Thanks for the reply. I had another look at this and calling ReleaseTerminal() and RestoreTerminal() either side of the <-m.sigworks well enough for my purposes.

Thinking about this some more, I can see that the reason my original program failed is because bubbletea puts the terminal into raw mode and not cbreak mode, which is what I expected (because of the talk of signal handlers).

It would be nice if there was a way for bubbletea to use cbreak rather than raw mode. But as I say ReleaseTerminal() and RestoreTerminal() seem to work well.

[JetSetIlly]

Happy with the solution