piotrmurach/tty-reader

Access line in event listeners (to read and write)

wrzasa opened this issue · 9 comments

wrzasa commented

Hi,

I'm playing with tty-reader, tty-cursor and tty-screen and would like to do a simple thing: when someone presses TAB while writing text in TTY::Reader prompt, move cursor to other place on the screen and put there e.g. number of currently read characters. I can hack it somehow with the tty-reader API, but I think it would be much easier if I could access the line object inside the reader's event code, e.g. like this:

reader.on(:keytab) do |event|
  print cursor.save
  print cursor.move_to(1, 1)
  puts "=> #{event.line.to_s.size}"
  print cursor.restore
end

It would give me also possibility to remove the TAB from the line to avoid placing it in the output string.

I believe it would make tty-prompt more flexible. It requires minor rearrangements in read_line while loop (especially the callback would be called after the line was updated).

Maybe I'm plainly wrong and just overlooked a simple solution? But if I'm right I can prepare a pull request.

piotrmurach commented

Hey,

Thanks for using the tty libraries!

The tty-reader is a direct extract from tty-prompt. The event callbacks style has been implemented as a way of decoupling different prompts from the underlying input logic. I haven't announced this library around since I wanted to give myself some time to build it up so that it can also be used for creating REPLs and other shell funky stuff. The road ahead is long and windy 😄

I'm currently rewriting the keys functionality which basically changes majority of internals and especially how #read_line works. Therefore, I would probably wait with any changes until I do this rewrite. It's important as some keys on different systems are working wrongly or are not recognised at all.

As far as your suggestion goes of exposing the line inside the even object. I think this is a matter of taste about designing apis. I'm not sure if exposing line object through the event is a good thing or not. I would need more time to think it through. It may well be that line could be a second yielded parameter? I really like your idea of increasing the flexibility though.

I really hope that I get time this weekend to work on the keys update.

wrzasa commented

I found tty-reader on gem list in tty README, so I didn't think it's internal lib ;-)

I proposed to expose the line through event because I thought it easier to implement, but my first thought was to add second yielded parameter ;-)

OK, if it's still significantly evolving it's probably better not to mess with your concepts with such small PRs. I'm waiting (im)patiently for the developments! ;-)

piotrmurach commented

The tty-reader isn't really internal per say but at the same time I haven't invested enough time to make sure it works in variety of scenarios outside of tty-prompt context. I'm fully aware that this library needs more work before it reaches flexibility of readline. However, I'm really glad you took the interest. It gave me extra motivation to work on it!

I have changed how the keys work but still want to spend some time to extract logic for line editing. After that it will be safe to think of new apis etc... One of the major things I plan to add is a completion feature. I need it for tty-prompt.

piotrmurach commented

Hey,

The newest tty-reader has been released for some time now. If you fancy taking another look at this functionality be all means submit PR and let's have a discussion.

piotrmurach commented

@wrzasa Based on your suggestion I have exposed the current line value on key event object. It is a string value as I didn't want to expose the Line internal API. I don't think anyone needs to be able to modify the line in any way. Again thanks for you suggestion! 👏

  • 🎉1
wrzasa commented

Thanks for this! ;-)

A lot happened in the meantime and for now I had to set my project aside. I hope to be able to come back and play more with the great tools you develop for cli in Ruby!

piotrmurach commented

I always revisit the issues but given I'm maintaining quite a few Ruby gems it takes time to circle back 😅 Hope we get to chat at some Ruby conference in the near future!

wrzasa commented
piotrmurach commented

I've never been to wroclove_rb. Just checked the site and it seems there is nothing for the next year sorted yet. Thanks for letting me know I will keep a close watch on this one in case I can make it.

  • 👍1