> > However, when I try using this in the larger context of xrepl, I've > found that I've completely broken it. > > ####### > $ ~/local/racket/bin/racket > Welcome to Racket v5.3.3.1. >> (require xrepl) > -> hello > -> world > -> help > #######
There's something funny with buffered input going on. If I do the following interaction on my pr-13350 branch, then the results are much better: ################################# 128-110-82-95:readline dyoo$ ~/local/racket/bin/racket Welcome to Racket v5.3.3.1. > (file-stream-buffer-mode (current-input-port) 'none) > (require xrepl) -> 1 1 -> 2 2 -> 3 3 ################################# So part of the problem I'm running into seems related to how Racket is block-buffering the standard input port. This probably messes with readline, which needs to look at the raw stdin object to make sense of it. I'm still very confused! How do FFI-wrapped C functions deal with standard input? Does that mean that they normally need to access stdin via Racket itself, since the port is probably eating blocks of stdin already? There are still a few oddities. * It's off by a little because of the extra newline, which I don't understand yet. Is that the newline right after the "(require xrepl)" that hasn't been consumed yet? * If I try to set file-stream-buffer-mode within an xrepl module, I see no benefit yet. I seem to have to do this at the REPL, before loading xrepl. Very confused... :( _________________________ Racket Developers list: http://lists.racket-lang.org/dev