Abstract stdin/stdout
I brought this up in antirez, but it seems this is the active fork now...
I think it would be helpful to abstract away the direct use of stdin/stdout constants into variables (that default to stdin/stdout) such that a pty could be swapped in, allowing for a socket input source.
I think it would also be helpful to allow for an event loop environment via a character reader API (reference http://www.delorie.com/gnu/docs/readline/rlman_41.html).
I find the idea interesting but it's difficult to judge it as I'm not an expert on the concepts involved.
Is it necessary to swap stdin and stdout to use a pty? couldn't you instead dup the stdin and stdout fds to your pty before invoking the program that uses linenoise? Hopefully you can correct me if I'm misunderstanding the pty idea. I also don't understand the relationship between pty and socket. Or why one would use linenoise through a socket. Is there a specific use case you had in mind?
The alternate interface API seems like a good idea although couldn't we just split a program into two threads: one that handles reading user input and another that does all the other event loop stuff? To try to keep the library reasonably minimal an in the spirit I would like to avoid adding extra ways to solve a problem - if the threading approach is not valid though it would be a good addition.
Cheers!
I believe it is necessary. There is a readline test harness example of it here...
https://github.com/alexmac/alcextra/blob/master/readline-6.2/examples/rlptytest.c
The use case I have where this request comes into play (which is not rare) is an interactive CLI hosted within an application. A user can ssh or telnet into the application and execute commands with the benefits of linenoise/readline ( socket <> pty <> readline <> appl).
There are embedded environments where resources are limited, so thread models and memory usage are optimized whenever possible. linenoise has strong potential here.
Thanks a lot. Unfortunately I'm just not educated enough on ttys and such to judge if this feature fits within the scope of linenoise. For now I think it would be best to implement that in a fork.
The event loop/call back stuff could be added though.
@brjoha, did you ever pursue this? I'm also looking for a way to use linenoise with sockets, and it would be great if you could share what you ended up doing.