Problems with detecting a keypress about tty HOT 7 CLOSED

I just found out that there is IO.raw, which both turns off the echo and does the "character" input. It also resets it back at the end of the block.

require "io/console"

IO.raw do |stdin|
  p stdin.getc
end

from tty.

I discovered another thing, IO#readpartial, which perfectly solved my problem.

require "io/console"

loop do
  keypress = STDIN.raw { |stdin| stdin.readpartial(3) }

  case keypress
  when "\e[A" then puts "Up"
  when "\e[B" then puts "Down"
  when "\e[C" then puts "Right"
  when "\e[D" then puts "Left"
  when "\x03" # Ctrl-C
    raise Interrupt
  when "\x04" # Ctrl-D
    exit
  end
end

IO#readpartial(n) reads at most n characters from the IO, and sees a "keypress" as a single input, which was exactly what I wanted. Maybe this is what you want to use in your gem, a "keypress" instead of a "character", because it's much more powerful (each "character" is a "keypress" as well).

from tty.

Hi Janko,

Great that you are giving this lib a go! Before I talk about this issue, my goal is for this library to become modular so that individual components can become much more robust and basically stand on their own merits. I realised I was short sighted trying to lump everything into one big blob. I have extracted few components such as pastel that I think got significantly better and got major issues fixed.

Regarding terminal queries and user input, I'm gonna extract that to separate component that going forward will allow for asking robust questions such as choose an option from menu, yes/no and basically nice way to gather input. I will work on it this coming weekend.

Usage of 'io/console' is good, however I found that for instance the JRuby doesn't support it. But obviously that's not a show stopper. I'd like to work with you on getting the interface to work intuitively. I'm open to suggestions and of course PRs. Agree that `shell.ask('...').read_keypress would better explain the intention. We could also provide some callback system that would yield on each key.

Any thoughts?

Best

Piotr

from tty.

Yeah, it's great that you started separating, now people can just use gems like pastel standalone (which probably has a frequent use case; I needed once just the coloring, for a custom logger).

That's great, I would like a separate #read_keypress, and then #read_char doesn't need changing, because it actually does what it's supposed to. I don't think that #read_keypress needs a callback (because it's blocking), it will just return when the user presses a key (returning that key). And if people want to wait for more keypresses, they could just put it in a loop, right?

One more thing that I wanted to ask, what if the key pressed is Ctrl-C? Because inside of STDIN.raw Ctrl-C won't terminate the process, it will just be treated as a regular keypress. My intuition says that we should just leave it to the programmer to rescue that case, since maybe he would like to handle Ctrl-C differently? But then again, if we raise an Interrupt error (it's what Ruby raises on Ctrl-C), then the user can also just rescue it. What do you think we should do?

from tty.

Agree with your point of separating the two methods. Also, agree that blocking io doesn't need callbacks. I suppose I was thinking of more general approach, for instance, allow users to subscribe to keepress to accomplish things like autocompletion, but that's besides this point.

From user point of view I imagine that Ctrl-C should bum you out of the client, that would be at least my expectation. Thus I wouldn't do anything special but stay consistent and throw an error and let developer handle that. Also, I would probably be tempted and make this behaviour the default for all the other methods. Thoughts?

from tty.

All other methods will already throw an error on Ctrl-C, it's just when you enable the "raw" method with IO#raw that this gets disabled. Ok, enough philosophing, I will work on the PR now 😃

from tty.

Hi @janko-m, just to let you know that I've released v0.1.2 version with your code. The release includes necromancer that helps parsing user input and will help with extraction of shell component later on. In future people will be able to use just the shell interface without other dependencies but I need to extract a bit more. I will keep your posted as I would like your input/opinion. Btw, I like your tic-tac-toe curses usage.

from tty.