I am using a node REPL in emacs on an ubuntu ec2 instance and I've noticed that whenever I type an unknown character, for example, "#" into the REPL the REPL will stop working and instead of having each line starting with '>' where I would enter my code I am getting '... ^[[5G'. If I hit C-c C-c then the REPL will return to normal. What is going on here?
I think that this might have something to do with comments. If so, how would I bring all of my code over to the REPL using C-c C-r if the first line is a comment?
In JavaScript # is an illegal token, not a comment (try inputting this in a browser JavaScript console). This generates a syntax error when evaluated, however the node REPL is trying to be helpful by buffering the command and prompting you for more input (...) in an attempt to recover from the error.
This would be the same behaviour here (as documented in the REPL source):
> { // syntax error!
... x : 1 // syntax error!
... } // recovered ...
{ x: 1 }
However, in your case I don't believe you can ever recover from the bad syntax.
Related
For some reason, Haskell on my machine does never return from any getLine call. For instance, I tried to run the following code straight from Learn You a Haskell for Great Good:
main = do
putStrLn "Hello, what's your name?"
name <- getLine
putStrLn ("Hey " ++ name ++ ", you rock!")
When I run it, the first line is printed, and I see my input when I type a name, however when I press Enter the program just blocks there and never prints the final line.
How should I fix this?
edit: I am running it from the Sublime IDE, maybe that has something to do with it
After doing a quick search on how Sublime runs programs, I found a youtube video (edit: and this SO post) which says that Sublime's "run program" functionality can only show output and isn't capable of reading input.
So it looks like you'll have to run your program from the command line or from within GHCi using :main. The latter might be the most convenient as Sublime actually supports a GHCi tab, so you can still do everything from within Sublime.
This seems to be a limitation in Sublime's Build command (assuming that this is what you're using).
Sublime executes the script using runhaskell, but apparently, it doesn't capture STDIN (which makes kind of sense - build results are usually read-only and not an interactive session).
Workaround: run your script from the command line with
runhaskell script.hs
and everything works as expected
I am using vim with Pymode to write python source code. I have the come across some strange behaviour which is intermittent but very annoying.
If I am in insert mode and type a full stop (e.g. self.method()), whilst typing self vim prints at the bottom
-- Keyword completion (^N^P) The only match
As soon as I type the full stop vim seems to freeze momentarily, then
-- INSERT -- appears at the bottom, but my cursor is now on the full stop, so that when I write method() it actually appears behind the full stop. I keep having to go back and move the full stop.
I can't figure out when it happens and when it doesn't, when I open a new file it doesn't happen straight away.
Any ideas on what may be causing this? I have only noticed it recently.
This is a problem caused by some combination of pymode and rope. Either way putting
let g:pymode_rope_lookup_project = 0
in your vimrc solves it apparently. See here for the pymode issue.
Running node in terminal will bring you into its REPL mode, with syntax highlighting (e.g. number is yellow, while string is green).
However, I'm not comfortable with it's default emacs-key-binding, so I follow some suggestion:
alias node='env NODE_NO_READLINE=1 rlwrap node'
This works great, I get vim-key-binding, but the syntax highlighter is disabled.
So I give a second try:
alias node='rlwrap -a node'
This time I get both vim-key-binding and syntax highlighter work out, but the are some bug e.g. when I type this into REPL mode:
> [1,2,3]
the output is correct (with syntax highlighting)
[ 1, 2, 3, 4 ]
but the input line from above has changed to
> [1,[1,2,3]
This bug is more annoying than having no syntax highlight.
Any idea to make this 2 things work well together?
P.S. I don't need tab-compilation (at least for this time).
When in a Haskell file, I use C-c C-l to run the command inferior-haskell-load-file which is intended to load the current file into the GHCI interpreter but Emacs just hangs until I hit C-g. Anyone know how I can get this to work?
GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-14 on allspice, modified by Debian
Using haskell-mode version v2.7.0
inferior-haskell-mode does some parsing based upon the expected ghci prompt. As such, if you change the prompt in a .ghci file, then it can't detect it.
For more information, see where haskell-ghci.el sets the comint-prompt-regexp value to determine what a prompt is.
;; GHCi prompt should be of the form `ModuleName> '.
(setq comint-prompt-regexp
"^\\*?[[:upper:]][\\._[:alnum:]]*\\( \\*?[[:upper:]][\\._[:alnum:]]*\\)*> ")
If you want to keep the setting in your .ghci file, then it may be possible to customise this settings.
Old question, but as I just ran into this today, I wanted to share how to actually customize comint-prompt-regexp since I had to figure it out.
This customization will recognize λ> prompts, or actually any single character before >), but it doesn't break the existing regex. In your .emacs:
(load-library "inf-haskell")
(defun my-inf-haskell-hook ()
(setq comint-prompt-regexp
(concat comint-prompt-regexp "\\|^.> ")))
(add-to-list 'inferior-haskell-mode-hook 'my-inf-haskell-hook)
You can add more dots to "\\|^.> " to recognize a longer prompt, but I wanted to keep it fixed-length for simplicity.
I had a similar problem caused by GHCi reporting some kind of error on startup, causing the Emacs haskell mode to wait for the GHCi prompt indefinitely (GHCi didn't show the standard prompt (Prelude>), but rather just showed >). You can try running GHCi externally and see if it reports any errors.
I got the same error message when I tried to use stack with emacs. For me, adding this line to my .emacs/init.el resolved the problem:
(setq haskell-program-name "stack ghci")
When working with the node.js repl, is there a way to quit a continuation line that node is being over zealous with?
For example:
$ node
> {- -}
...
And pretty much everything you can type then gives you another continuation line. Ctrl+D quits the whole repl.
Obviously I don't want to go around typing {- -} all the time, but I do find I often type something erroneous when I'm using the repl to experiment. Then I have to quit the repl, and loose all the bits in memory.
You can also type:
.break
Type
.help
for more REPL options... the .clear command may also be useful because it breaks and clears the local context, in case you want to save yourself the trouble of exiting and restarting the repl.
Sorry - I really should experiment more and Google less.
The answer (at least on Ubuntu) is Ctrl+C.
Ctrl+C first quits any continuation. Then if you hit it again prints
(^C again to quit)
Then quits, as it says.
In the interest of making this question more useful, just tested this and the same thing works in Python's repl, Guile. But doesn't work in Rhino, where it quits the repl entirely.