MinTTY issues (characters, Ctrl+C, etc. get eaten or messed up)

[mehrdadn]

Basically, if you try to fire up Git-Bash and try to scroll through history (holding Up/Down for a while) and then start typing, you'll frequently see it gets messed up pretty fast: keypresses will appear to get eaten and then spit out suddenly, Ctrl+C will start appearing as ^C instead of interrupting the prompt, etc.

This happens on every recent version that I've tried; it's not a recent issue. Took me a while to track down the cause, but it turned out to be set bell-style visible in /etc/inputrc.

This may well be a bug in MinTTY itself, but either way, I would consider just avoiding that option regardless. Maybe just set it to none instead of visible.

[dscho]

if you try to fire up Git-Bash and try to scroll through history (holding Up/Down for a while) and then start typing, you'll frequently see it gets messed up pretty fast: keypresses will appear to get eaten and then spit out suddenly, Ctrl+C will start appearing as ^C instead of interrupting the prompt, etc.

I cannot reproduce.

[mehrdadn]

Not sure how else to have you reproduce this unfortunately, maybe someone else can repro. But is that a setting you need either way? If it's harmless to change then maybe you could trust me that it's a problem... :-P I don't know if the visual or audible bells even work (I haven't managed to get them).

[dscho]

is that a setting you need either way?

For over a decade, Git for Windows did not play an annoying sound when you happened to hit the Delete key in a Git Bash where there was nothing to delete.

I do not plan on introducing that annoying sound now. Because you know, between you and me? You would not hear any complaints at all. You're not the maintainer. I would. Many. Many. Many, many, many complaints.

[mehrdadn]

I don't think none should introduce any sound? I thought the setting to enable sound would be audible, not none. (Although I haven't even managed to get sound with audible...)

[dscho]

I don't think none should introduce any sound?

The way the "visual bell" feature typically works in Unix applications is that if you enable it, the audible bell is suppressed and a visual "bell" (i.e. some sort of flashing inverting foreground/background color) is used instead. If you turn off the visual bell, it is back to the audible bell.

So yes, I think that if you say "visual bell: none", that would (or should) turn on the audible bell.

[mehrdadn]

I think you're confusing audible with none? The documentation is pretty clear none doesn't ring anything:

bell-style
Controls what happens when Readline wants to ring the terminal bell. If set to none, Readline never rings the bell. If set to visible, Readline uses a visible bell if one is available. If set to audible (the default), Readline attempts to ring the terminal’s bell.

[dscho]

I did not read the documentation, indeed, but I seem to remember that that was the reason why we introduced it. Maybe you can investigate under which circumstances /etc/inputrc is used? I think in Git for Windows 1.x we seemed to try to use xterm and that might have read it, too?

[mehrdadn]

I'm confused, even without reading the documentation, why would none and audible ring the bell? That just wouldn't make any sense.

As for xterm... you mean on Windows? I didn't even know there's xterm for Windows... is there a binary I should download? And are you saying I should download Git for Windows 1.x? Sorry I'm really confused what you want me to do.

Also, is the fact that MSYS2 has it set to none not enough? I'm struggling to understand what scenarios you're trying to support.

[dscho]

As for xterm... you mean on Windows? I didn't even know there's xterm for Windows... is there a binary I should download? And are you saying I should download Git for Windows 1.x?

Yes, in the beginning (i.e. in 2006), we tried to use xterm instead of the default console. Of course, that's long past, but that's from where our original /etc/inputrc comes.

I am not sure what we would break now if we changed it, which makes me hesitant to change it.

[mehrdadn]

But msys2 has it set to none? I'm so confused...

[mehrdadn]

In your ideal world what could I possibly do to convince you to give it a try? Download git for windows 1 and extract xterm from it? Then what do I look for? What is considered "breakage"? Should it beep or not beep? Or should I watch out for a different kind of problem? I'm so confused what you're hoping I would do on my end...

[dscho]

what could I possibly do to convince you to give it a try?

I am not even sure when/why we introduced it. You could follow the history down to probably https://github.com/msysgit/msysgit/commits/master/etc/inputrc and once you found the reason, argue either that I misremember, that I remember correctly and it is no longer an issue, or that there are other reasons to believe that this won't end up with dozens of bug reports that I have to deal with.

[mehrdadn]

@dscho: That seems pretty easy. The very first (and only?) time that line is introduced, it is set bell-style visible and the justification written in the commit message is "Kills the annoying bell".

Which makes sense, because when it's unspecified, the default is audible, so this would have killed the audio just as claimed.

Hence I see no indication that none has ever turned on, or would ever on, any bell like you claimed, and I can't imagine what bugs anyone might encounter as a result of setting it to none...

[dscho]

The very first (and only?) time that line is introduced, it is set bell-style visible and the justification written in the commit message is "Kills the annoying bell".

Ah, and it was not about xterm, but about rxvt...

Hence I see no indication that none has ever turned on, or would ever on, any bell like you claimed, and I can't imagine what bugs anyone might encounter as a result of setting it to none...

How about turning this into a nice commit message and then opening a PR?