Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keypresses are ignored upon reaching 2nd form (examples/gh) #281

Open
patricklatorre opened this issue Jun 16, 2024 · 6 comments
Open

Keypresses are ignored upon reaching 2nd form (examples/gh) #281

patricklatorre opened this issue Jun 16, 2024 · 6 comments
Labels
bug Something isn't working input

Comments

@patricklatorre
Copy link

patricklatorre commented Jun 16, 2024

Describe the bug
When running examples/gh, 1-2 keypresses are always ignored upon reaching the 2nd form.

This issue seems to only occur when there are multiple forms.

To Reproduce

  1. Clone the charmbracelet/huh repo
  2. cd ./examples/gh && go run create.go
  3. Choose option "charmbracelet/huh"
  4. Type in Title input field (initial keypresses are ignored)

Expected behavior
Input field (2nd form) should immediately respond to keypresses.

Desktop:

  • OS: Win 11
@caarlos0
Copy link
Member

could not reproduce it here 🤔

maybe it's fixed on main?

@noahstreller
Copy link

I have the same issue. I am trying to create a "dynamic" form, which seems to be kind of difficult with "huh" due to its linear nature; maybe I am doing it incorrectly.

I need to create a new huh.Form for each interaction, causing first keystrokes to be ignored for some reason.

Demonstration of the issue:

huhissue.mp4

Here is the file, where I am attempting this. I am aware that the code is really horrible so far, I'll be refactoring it soon (it's my first Golang project 😄)

@noahstreller
Copy link

noahstreller commented Sep 3, 2024

I could also reproduce it using following file:

package main
import "github.com/charmbracelet/huh"
func main() {
	huh.NewInput().Run()
	huh.NewInput().Run()
}

The second input will ignore the first keystroke.

I am able to reproducing it with Windows 11, and it occurs with both cmd and PowerShell. It does not occur on Linux.

@gr5vg
Copy link

gr5vg commented Oct 29, 2024

Can see this behaviour too as of latest version

@sininen-blue
Copy link

also seeing this behavior as of latest version (v0.6.0), on windows 11, nu shell, wezterm

@caarlos0 caarlos0 added bug Something isn't working input labels Nov 26, 2024
@nojaf
Copy link

nojaf commented Nov 28, 2024

I believe the actual problem is mentioned in charmbracelet/bubbletea#1167

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working input
Projects
None yet
Development

No branches or pull requests

6 participants