I use Emacs for many things (the list seems to be growing every day). I like to have several frames open (so I can keep them in separate workspaces), so I first start it with emacs --daemon and then connect various clients to it with emacsclient -t.
One thing I have recently added to that list is writing papers. I write in Markdown, which allows easy version tracking with Git. In order to make it more readable, I usually split the frame into 3 or 4 windows vertically, and use follow-mode to split the paper between them.
I recently ran into a problem with this setup. Emacs would randomly stop accepting connections, and any time I ran emacsclient -t it would hang, never opening the frame. It took me a while to figure out why it happened, but I finally did. To reproduce:
Start emacs with emacs --daemon
Connect the first client with emacsclient -t <file> where <file> is some plaintext file.
Activate follow-mode with M-x follow-mode
Attempt to connect another client with emacsclient -t. This client will hang and never connect.
Deactivating follow-mode after that point had no effect, clients were still unable to connect. If I never activate follow-mode, I never have a problem.
I also tried it without loading any init files (emacs --daemon --no-init-file --no-site-file), with the same result.
I'm running GNU Emacs 23.4.1, from the Ubuntu software repositories.
Why does this happen?
Looks like a bug in follow-mode (I cannot reproduce it with with emacs 24.3). Upgrading emacs would be a solution for fixing the problem.
This seem to be the official thread for this problem, which provides some adittional information and a workaround for those unable or unwilling to upgrade emacs.
Related
I have been really enjoying having emacs load as a daemon when I login and using emacsclient -c to pop open an emacs window superquick.
However, I often have multiple emacs windows open at a time. Each one is dedicated to a particular project. Before I used emacsclient each of these emacs windows would be independent of the other, but now, they share the same set of buffers.
How can I continue to use emacsclient, but have the windows act independently?
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
On a daily basis I:
use multiple workstations running either Linux, Windows, or MacOS X
edit files on additional Linux hosts that are not any of the workstations mentioned above
The only common element here is that the internet connects all of these hosts: workstations and servers. I can keep all of the config files in sync on my workstations too and can run an X server on all of them. What's the right way of running emacs? I don't want to sacrifice any features.
In my ideal world I can type 'emacs foo.txt' on a remote host and some magic happens via X forwarding to display the file in my workstation's existing emacs session.
Non-solutions
tramp: when I'm manipulating a remote host an editor is just part of my workflow. I need a terminal open so I can run other commands quickly. tramp is all wrong for this.
ncurses emacs: sucks, I want the graphical kind
If you don't have a positive answer to my question, please don't just guess. Thanks.
Have you tried tramp with eshell? You can "cd /remote.host:/some/path" and edit files from there, and if you type a non-built-in, it fires up a ssh pipe to run it. Quite slick.
I fail to see why tramp is not a solution. You can edit using tramp, and do whatever you need in a terminal using xterm+ssh.
Well, if you can setup X clients on your Windows and OSX boxes, you should be able to run an X version of emacs on any of those platforms and set the display back to your workstation. That would give you your nice WIMP interface.
However there are a couple of solutions to keeping a terminal open to the same box. One is to just telnet into it twice. Once for your emacs session, and once for a shell.
The other option of course is to use meta-x shell to bring up a shell buffer inside of emacs. A true emacs guru prefers to run their OS inside of emacs, rather than the other way around. :-)
The approach I use is based on source controlling the Emacs scripts and important common files (using Git). This gives me a consistent code base so I don't have to remember which host has which script or file (or version of what I'm looking for). Git is particularly well suited to supporting this mechanism and I've pretty much got in the habit of updating the master origin repo daily. Within the scripts (both Emacs and bash shell scripts) I use machine tailored code to handle local requirements. This system has been in place now for well over a year and I find it to be quite effective. This is a technique I've seen recommended for some number of years. I found it clunky with CVS and Subversion but git feels tailored for the job. That said, I like the solution you selected as a complimentary tool and look forward to adding that to the mix.
I use Emacs remotely using X-Server in a Windows client and Linux server. I noticed that I can halt it using ctrl-z and then type fg 1 to get it working again. Is there some way that I could get it to halt on the machine that I am on, and then log into a different machine and start where I left off? When I start a new ssh session, the emacs job isn't associated to my terminal. There must be someway to "steal" it.
Also, maybe there's an Emacs feature that will do basically the same thing. However, I think closing and re-opening all my files and buffers would take quite a while.
Expanding on the idea of using emacsclient, you can look at what what someone did to solve the problem of editing a file from a different machine than where (s)he started running Emacs.
As of Emacs 23, you can run emacsclient in terminal windows using the -nw option.
Other solutions you might want to try are to use:
gnu screen
vnc
For years I used screen to "attach" and "detach" from a virtual terminal that sounds like your usage model. If you have the ability to use graphics... vnc is really great, just do your work in a vnc session and connect to it any machine.
And your last idea is already implemented by the package desktop (which is bundled with Emacs). Take a look at the wiki page for session management, which includes other alternatives to desktop, as well as add-ons for desktop to lazily load files.
You can run emacs as a server, and use emacsclient to connect to it. You can open multiple connections to the same emacs server, via ttys or X11.
When doing this, C-X C-C will close your connection, and leave the server running.
A simple way to do this by invoking emacs as follows. This will connect to the server if one is running, or create one.
emacsclient --alternate-editor="" -c
Sometimes I will be at work and have to run out the door leaving my Emacs session as it was. Later, I will open an Emacs instance to the same machine (usually using remote SSH) and find that I have files open in Emacs. Now the good news. Emacs allows you to "steal" those files using M-x recover-this-file. I recommend one of Trey's solutions if you can plan ahead. If not, you can use this recover file technique to keep progress moving.
I was trying out tramp-mode, but now I cannot seem to get rid of it.. Whenever I start emacs, it spends about 20 seconds going through various tramp-related initialisations..
tramp: Waiting 60s for prompt from remote shell
tramp: Setting up remote shell environment
..and so on.
How on earth do I unload tramp? grep'ing my ~/.emacs.d found nothing aside from the plugin itself (which doesn't seem to be loaded anywhere..)
I've cleared the recent-files history, but that made no difference..
Aha, I found where tramp was being loaded:
Loading /Users/dbr/.recentf...done
Loading tramp-mode..
I had a two files in my ~/.recentf file-history which were opened with tramp, removing them stops tramp from loading..
I just found this section of the emacs wiki explaining the problem,
When using TrampMode with recentf.el, it’s advisable to turn off the cleanup feature of recentf that attempts to stat all the files and remove them from the recently accessed list if they are readable. Tramp means that this requires recentf to open up a remote site which will block your emacs process at the most inopportune times.
(require 'recentf)
(setq recentf-auto-cleanup 'never) ;; disable before we start recentf!
(recentf-mode 1)
Another possibility is a listing in ~/.ido.last, if you are using ido-mode. In that case, the remedy is just "rm ~/.ido.last".
It sounds to me like you have a file that is opened via tramp and is being reopened at startup. Have to set emacs to restore your session?
From the tramp faq:
How can I disable tramp?
Shame on you, why did you read until now?
If you just want to have Ange-FTP as default remote files access package, you should > apply the following code:
(setq tramp-default-method "ftp")
Unloading tramp can be achieved by applying M-x tramp-unload-tramp. This resets also > the Ange-FTP plugins.
Note that I haven't tried this but hope it works for you!