How can I get the Spacemacs test runner to work? It doesn't fail to run according to the messages buffer. It simply doesn't show the test report buffer and I have no idea what command to use to get it to show. I thought it was hidden in my buffers list but alas it is not there.
I am using Fedora release 30 (Thirty) running GNU Emacs 26.2 installed via dnf.
Related
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I'm working through the following tutorial on Clojure. I've just installed both Emacs and Leiningen. If invoked separately, both work. However, when I am trying to invoke cider-jack-in, as described in the tutorial:
Using Emacs, open the file clojure-noob/src/clojure_noob/core.clj,
which you created in Chapter 1. Next, use M-x cider-jack-in. This
starts the REPL and creates a new buffer where you can interact with
it.
that hangs forever after the last message:
Starting nREPL server via lein repl :headless...
You can run the command `cider-jack-in' with C-c M-j
Starting nREPL server via lein repl :headless...
What am I doing wrong?
Edit: To solve the problem, I upgraded leiningen from 1.7 (that's what apt-get installed) to 2.6.1.
Recently cider changed so you no longer need to add things to ~/.lein/profiles.clj to install cider-nrepl and clj-refactor. Cider will take care of that now. You should remove that part from your config.
In general for these situations it help to run lein from the command line first and make sure it can actually get the projects dependencies. Most of the times it's sitting there downloading a jar file at 3 bytes per second and not actually stalled. Other times it's failing with SSL/TLS certificate validation problems.
I am trying to set up Emacs and GDB such that I can have the gdb-many-windows option running. However, m-x gdb hangs after running any binary, and Emacs starts consuming 100% CPU and becomes unresponsive.
I am running on:
OS X 10.10.1.
Emacs 25.0.50 (the one in Homebrew)
GDB 7.8.1 (the one in Homebrew)
My Emacs setup is here: https://github.com/ChrKroer/emacs-setup
Here's what happens:
I run some binary with m-x gdb and then 'gdb --i=mi [name of binary]'. Everything works fine, the correct windows set up and everything. I then give the command 'run' to GDB, and it runs the code correctly. But once the code finishes, Emacs becomes unresponsive and start consuming 100% CPU power. This happens even with a simple hello world program. I have tried giving various options like --annotate=3, --fullname etc.
If I instead run m-x gud-gdb, I can run the same binary just fine, gdb exits normally and I can continue using Emacs.
Any help would be much appreciated.
The bug is confirmed in my mac. What's more, emacs with the same configuration (actually no configuration at all) works well in my Linux machines. So it is a bug related to Mac OS X.
Update:
It seems that some modes/plugins in emacs which conflicts with "gdb". When I run it without loading anything in .emacs, it stops hanging emacs when gdb debug finished.
I will try to track which mode causes such problems, and report it here.
It seems that many modes could lead to freezing emacs when gdb finishes debugging, e.g. "helm" and any modes using helm, "function-args" (which enables some features of helm in its source codes)
To my configuration, dozens of modes enable, helm is the critical mode that cause gdb to freeze emacs when it reaches the end.
It's not due to helm, but due to semantic-mode, which might be enabled when you want to use helm-semantic-or-imenu.
Conclusions:
It is caused by semantic-mode, which performs poorly in Mac OS X, even its basic functionality has bugs. Under Linux, it doesn't have any obvious issues, that's why gdb works in Linux. Search around your .emacs and make sure disable all semantic-mode, then it should work.
Note that, even though you disabled semantic-mode before run gdb, if semantic-mode is initially enabled, it will still freeze emacs. semantic-mode has be initially disabled.
Thanks to thierryvolpiatto for help in debugging:
https://github.com/emacs-helm/helm/issues/1168#issuecomment-140132443
i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.
I'm checking out a segfault in one of our apps. A short time after starting the app, the main gdb status bar changes to:
(Debugger:run [signal-received])
A (gdb) prompt appears but the contents of all other windows remain unchanged (empty). Typing anything at the prompt does nothing - gdb appears to be hanging. Running the same steps on the command line results in the expected output from gdb with a complete and correct backtrace.
This is my first time debugging with the -i=mi integration between emacs and gdb. I'm using emacs 24.2 and gdb 7.5.
Are there any suggestions on how I can debug this further?
Is it possible to reduce the level of integration? Would that allow me to determine which area is causing the problem?
A final point is that the initial loading of the app takes around 70s compared with around 3s from the command line.
Load time can be reduced by setting gdb-create-source-file-list to nil (use customize). See the documentation for what this does and why it substantially increases load times in some instances.
You can use M-x gud-gdb to use the old gud mode (i.e. without the mi interaction). Less fancy but more reliable.
It appears that gdb-ui from emacs 23 will still work in emacs 24:
Find a copy of gdb-ui (In my case gdb-ui.el.gz and gdb-ui.elc from a backup)
Place these into a directory (I have added ~/emacs-modes)
Then add the following to your .emacs:
(add-to-list 'load-path "~/emacs-modes")
(require 'gdb-ui)
Running gdb will now use the old --annotate=3 mode rather than -i=mi.