Open craigyk opened 11 years ago
Hi Craig,
The file command.ls
contains the source code for the repl, which is based on the standard node readline with a fancy completer.
I've done some experimenting with this in the past (LiveScript v1.0.0) and found that I got two version of the LiveScript REPL running at the same time. So when I typed input, it was doubled and went to both interpreters:
livescript> ttyyppeeooff llss
'object'
livescript>
'object'
instead of:
livescript> typeof ls
'object'
You can test this by copying lib/command.js
to lib/repl.js
and add
if (typeof module !== "undefined") module.exports = repl
to the end of the file and then do:
repl = require './repl'
If you are just doing one line experiments, try this instead:
LiveScript.run 'console.log 42; return typeof LiveScript'
which works fine as long as you are not putting anything in global scope.
Cool, thanks. Do you have any recommendation as to how I might get the instance of readline running the actual repl so I can hook into its events? I'm trying to figure out the cleanest way to persist the command history, lookup previous commands, etc. (I'm trying to recreate all my favorite python repl modifications in lsc)
Nvmind, I found a bunch of stuff attached to the LiveScript
global.
ah, but from looking at the code the readline instance never gets attached to the global LiveScript object, so there isn't an easy way to access this without changing the lac lib/command.ls
code.
It would be cool if when run in interactive mode, lsc looked for a configuration script, passed it the global for modification, before starting. That way one could attach extra handlers for searching command history, and persisting the history to disk.
can the repl code be split out so that it's it own callable module?
that way I can use something like:
Would be really useful when experimenting with code or debugging, interactive break points. Bonus: hitting ctrl-D breaks out of the repl and resumes normal control flow.