I've been playing with LispCabinet off and on for a bit, learning in my spare time. What works on my PC at home, and my work PC at my old job, seems to freeze Emacs or SLIME at my new job.
I'm going through Practical Common Lisp for a refresher, and this function:
(defun prompt-read (prompt)
(format *query-io* "~a: " prompt)
(force-output *query-io*)
(read-line *query-io*))
works perfectly at home. Running it at work, however, freezes after entering a few characters until I kill the interpreter. I've narrowed it down to
(read-line *query-io*)
as running that by itself will cause a freeze. The following also fail:
(read *query-io*)
(read-line *standard-input*)
(read *standard-input*)
I'm completely stumped as to what could be causing this. Any ideas?
I'm running LispCabinet 0.3.3 on Windows 7 Pro SP1.
LispBox works fine, but even reverting to earlier versions of LispCabinet, I still encounter the same failure.
Batch files are intended only for execution from the Emacs command shell or external cmd shell launched form the '((' menu (all environment variables are set up during the Emacs initialization).
I just tried to execute the code you posted on the stackoverflow in
the SBCL SLIME REPL (it also could be launched from the '((' menu), and it works fine on my installation.
The issue is still present in the shell and I suppose that this is an SBCL unicode I/O issue (LispCabinet uses unofficial version of SBCL).
You may try to install the official version into the '/bin/sbcl/' or use ClozureCL instead, if you want to use the command shell instead of SLIME REPL (but SLIME is much more convenient).
Related
I tried but get error: Process shell exited abnormally with code 255.
Mainly want this for SSH, and avoid Cygwin or plink/Putty.
I have this in config:
(setq explicit-shell-file-name "C:\\Windows\\System32\\bash.exe")
(setq explicit-bash.exe-args '("--noediting" "--login" "-i"))
(setenv "SHELL" shell-file-name)
(add-hook 'comint-output-filter-functions 'comint-strip-ctrl-m)
Thank you
I use Bash for Windows with the latest Windows Creator's Update and Ubuntu 16.04 they have included. It runs quite well on Visual Studio Code and Cmder (a shell app like MobaXTerm etc). I also use ZSH instead of Bash (with oh-my-zsh and powerline9k) but i had some adjustments to do (and, it takes time to load, but i've read somewhere that Microsoft is working to fix this slow issue).
To be honest, it's a good way to replace Putty, but it has to grow a little. There's a lot of network tools that can't work on WSL for example.
I know the pain to prepare a Cygwin or use Putty, but you can take a look on MobaXterm, a really good ssh client that includes a package manager to allow you to do a lot of things from your Windows. I don't know if they use Cygwin like in the past ... But it's a ready-to-use solution with local bash shell.
To finish this and maybe help you, here is my startup line to run WSL / Bash for Windows in Cmder: bash -l -i -cur_console:p -c zsh. If you need any more information just ask :).
I am running a cygwin shell under windows 10 in which I start a "screen" session and under that the cygwin version of emacs (24). If I do M-xshell, it starts a cygwin (bash) shell just fine. So for most of my programming I'm happy. However, if within the cygwin shell I run "cmd" to get a "DOS prompt". I get this weird error message from emacs, "Waiting for process to die" (and some more text about hitting ctrl-g). I also get the same message, if I set the shell to be cmd by setting "explicit-shell-file-name" when I run shell. (That's actually what I tried first.)
Now, if hit C-g (perhaps twice?), the shell appears and cmd appears to be running, but I'm not certain of the state of things.
Has anyone else seen this error message? Googling for it returned nothing useful. Is there some incompatibility between the cygwin build of emacs and running cmd? Any hints on how to get around this problem?
Alternately, is there any way to send "builtin?" "DOS" commands (like MKLINK) under bash to a DOS box? How about running .cmd files? I really hate running a separate DOS box (not under emacs) and sometimes I need to do "DOS" things (and usually want the output captured in an emacs buffer).
I've switched from ipython 0.10-11.1 to 1.1.0
Now, using Emacs together with the new ipython version I run into the following two problems:
1) Tab completion in Emac's ipython py-shell (C-c !) stopped working for me. Say, if I try to complete 'pl' into 'plot' and so pl<Tab>, the only thing I get in the minibuffer is
Can't find completion for "pl" based on line pl
There are many similar reports about this on the web, however none of the fixes I found solve the issue for me. In particular the additions to ~/.emacs/init.el suggested at http://www.emacswiki.org/emacs/PythonProgrammingInEmacs, in section IPython just don't 'do' anything.
2) When I start the py-shell on a any given buffer foo.py, which is open within one of several Emacs subwindows, then, all other subwindows, except for the one corresponding to foo.py and the newly started (ipython) py-shell get closed.
Both of these issues where absent in ipython 0.10-11.1. Anyone has an idea?
My Emacs version: GNU Emacs 23.2.1. My ipython.el version: defconst ipython-version "0.11" from https://github.com/ipython/ipython/tree/master/docs/emacs
Completion from a (I)Python-shell is just TAB
C-c ! from inside a shell should open another shell, but seems broken indeed, resp. it's not available.
https://bugs.launchpad.net/python-mode/+bug/1234539
Fixed in trunk meanwhile.
BTW to open a second shell from inside, C-u M-x python should work.
Did you set py-python-command-args accordingly?
Assume plot needs option -pylab.
Troubleshooting:
Start with Emacs -Q from the directory where python-mode.el lives.
Open python-mode.el and evaluate it.
Open a --maybe empty-- file with ending ".py".
Python-mode should be switched on.
M-x python RET
a regular Python-shell should appear.
M-x ipython RET
an IPython-shell should open.
Always call (I)Python-shell from a python-mode activated already.
Otherwise shipped python.el or other stuff might come between.
Link shows TAB-completion with IPython-1.1.0 at work:
https://launchpadlibrarian.net/152211804/ex.png
The previous answer does not provide any clue for how to get TAB-completion to work with IPython-1.1.0 and GNU Emacs 23.2.1. In fact the troubleshooting steps, starting from a bare-bones Emacs, do not lead to an IPython-shell with working TAB-completion. Moreover the image at https://launchpadlibrarian.net/152211804/ex.png claiming TAB-completion at work with IPython-1.1.0 depicts an Emacs 24.3.50.1, rather than an Emacs 23.2.1 which I was referring to in my question.
For me the solution was: get rid of IPython-1.1.0 reinstall IPython 0.10-11.1.
(That leaves you without the more recent notebook feature - which is fine if Emacs is at the core of your Python workflow anyway)
I'm a long time GNU/Linux user. Even though OSX is much like GNU/Linux is many ways, it differs in some. For example, when I install Firefox I expect to be able to run firefox in a shell to start it. But not in OSX.
That gives me some trouble when running Emacs batch scripts. Lets say I have this script:
#!/usr/bin/env emacs --script
(message "Hello world!")
I can run it without any problems. But I'll be using the emacs builtin to OSX. And most of the times that's not possible since the Emacs version is pretty old.
Installing Emacs from scratch made it possible to create a Bash-script, which called some emacs binary file.
But installing Emacs from http://emacsformacosx.com/ I can not make this work. Can anyone think of a solution for this?
(1) Launch Emacs.
(2) Open Activity Monitor. (Applications > Utilities > Activity Monitor)
(3) Find Emacs in the list of running processes, under "Process Name".
(4) Select it.
(5) Choose "Inspect" from the Toolbar.
(6) In the window that opens, choose the "Open Files and Ports" tab.
(7) The name of the Emacs executable currently running should be the second line in the list. (The first line should be /Users/yourusername.) In my case it's /Applications/Emacs.app/Contents/MacOS/Emacs, which is pretty standard.
Yes, you dig out the path to the Emacs app emacs.
I've got X EMACS on my machine (not an emacs app), but the path will be something like
/Applications/Emacs.app/Contents/bin/emacs
You can find the exact path with ls from the command line.
I installed Emacs 23 on OS X (the NS/Cocoa variant) and I got the following error when I tried to run ssh from a shell inside emacs.
"pseudo terminal will not be allocated because stdin is not a terminal".
Searching around the web tells me that it is because stdin is somehow a pipe instead of a real tty. I confirmed that by running stty.
Unfortunately, no one really seems to know how to fix it. There were suggestions to try and modify process-connection-type (some said set it to nil while others said t) but unfortunately, neither seems to work.
How do I fix this and get back usage of ssh (and I guess other tools like ftp, latex and anything that needs a tty) inside emacs's shell?
[update: I know of M-x term but that isn't a solution for me. I have confirmed that this works for me on Carbon Emacs 22.3 so this might be something specific about the NS post)
I figured this out. I had some piece of elisp in my .emacs which was setting process-connection-type to nil. Though this was needed for Carbon Emacs, it doesn't seem to be needed for NS Emacs 23. Setting it to t fixes it
are you using M-x shell or M-x term, term is a full blown terminal emulator that will allow you to run any console application you want.
M-x ansi-term
Character to defy 15 char limit.