When I launch emacs in console mode or in terminal with -nw option, emacs launches in terminal but none of keys work. I cannot type anything or even cannot exit by C-x C-c. Though I can see a blinking cursor. Same emacs works fine in GUI mode. Any clues will be helpful. I'm running debian 2.6.
I finally resolved the issue by installing emacs23-nox. Probably it installed any missing dependency. Now launching emacs in terminal mode works. Interestingly, when I had uninstalled and installed emacs again, that did not resolve the problem. Anyway, I'm all set.
Related
Hi I'm running Linux Mint 19 and I have just installed vscode using the snapd package manager. I've not used vscode on linux before as my usual editor is emacs. However, on a fresh new install of vscode, the integrated terminal does not work, there is just a non blinking cursor in the top left of the screen, but no prompt and no keyboard strokes are registering. This appears to be a common problem as there are a lot of posts about it if googled, but they are all for Windows versions and none of the solutions that I'm able to try do anything. I've tried to open a new terminal window, but the same thing happens I just get two terminal windows that I now cannot use. I've also tried checking the box that says Code-runner: Run In Terminal, but that does nothing either. What can I do to get this to work please, I looks to me like it is just not connected to either a bash or Zsh(which I normally use). Any help on this would be appreciated.
Instead of starting vscode with its default shell script (usually located on /usr/share/code/bin/code), the integrated terminal only works for me when starting it directly from the compiled binary (typically found on /usr/share/code/code, which is the same as the launcher created by the installer:
/usr/share/code/code --no-sandbox --unity-launch %F
While I searched for a solution in the past I've also noticed that lots of folks solved similar problems just by adding --disable-gpu flag, so might be worth checking out as well.
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'm trying to follow a very simple example to get started with Julia using ESS. But the very first command:
using DataFrames
results in emacs' spinning slash, nothing else happens, and the command prompt is not restored. This is emacs 24.3.1 on OS X 10.8.5, ess-20140304.2344 installed via emacs' package system. In my init.el, I have
(require ess-site)
(setq inferior-julia-program-name
"/Applications/Julia/Contents/Resources/julia/bin/julia-basic")
Note: /Applications/Julia is a softlink to /Applications/Julia-0.2.1.app
I tried the "using" command with the Julia.app terminal and it worked fine.
Tried it using julia/bin/julia-basic in an iTerm2 session and it hung. Tried julia/bin/julia-readline in an iTerm2 session and it hung. Tried julia/bin/julia and it worked in iTerm2 but not in emacs, which is strange since that's just a link to julia-readline. Tried putting julia/bin on emacs' exec-path. Nothing seems to work.
Any suggestions?
I've been trying to get tramp to work for Emacs and was having some problems so I upgraded my Aquamacs to the latest version. Ever since then I've had massive problems with shortcuts. C-x C-f no longer works as find-file and instead does next-buffer. If I try to remap it back to find-file in my .emacs file it still doesn't work. Though I have managed to map C-x C-o to find-file temporarily. Several other shortcuts are also broken inexplicably (with no sign of anything in my .emacs file). I've tried deleting my .emacs file completely, but it doesn't refresh back to the original shortcuts though I do know that it is reading that file because when I do make some changes ( such as C-x C-o mapped to find-file) it does reflect this. However, even when I delete the .emacs file it still keeps the color-face I chose in it.
It's also giving me problems with tramp still in that I get the following error even though I can ssh to the exact same remote host just fine when using a shell window inside of Aquamacs:
"ssh: Could not resolve hostname ssh: nodename nor servname provided, or not known. Process tramp/ssh ssh exited abnormally with code 255"
I've tried reverting to older versions of Aquamacs, deleting the application and reinstalling, but nothing seems to work. Any advice would be greatly appreciated.
Mac OS X 10.6.8, Aquamacs 2.4 Emacs 23.50.1.
I asked a question just yesterday which caused this new issue. gdb within emacs on Windows
Basically I was installing a QT sdk which asked me to uninstall MSYS which I did & I hosed my emacs/gdb interaction.
Here is the gdb_init file that I'm using. Before the uninstall of MSYS this worked fine. Now after it, the breakpoints are working but I am not getting my code in another window with the little red dot on the left margin for a breakpoint.
file ~/../sandbox/trunk/current-win32/debug-bin/sm.exe
dir ~/../sandbox/trunk/src/mgr/view
dir ~/../sandbox/trunk/src/mgr/view/appstatus
dir ~/../sandbox/trunk/src/mgr/controller
break widget.cpp:176
break book.cpp:72
break TcpClient.cpp:660
break mainwidget.cpp:1474
The steps I'm running in emacs
M-x gdb
source ~/gdb_init
run
(It will break but not give me the code along with the breakpoint)
Any ideas what I'm doing wrong?
It turns out I was using the Cygwin version of gdb and had that in my system PATH. For some reason that didn't work out and I was getting errors in gdb within Emacs. Once I installed MSYS(mingw) & the gdb install on their download page and put that in my system PATH then I was back up and running.
I had the exact same problem: windows emacs, cygwin gdb, and the source buffer did not update with the "=>" pointer to show the code location. Downloaded mingw gdb.exe from here: http://sourceforge.net/projects/mingw/files/OldFiles/and selected that gdb with M-x gdb and it worked perfectly.