When you are saying "I am using tramp via ssh" I suppose you open a file like /ssh:host:/path/to/file. This is supposed to use always the ssh method. If you want to use the scp method, you shall use /scp:host:/path/to/file. This uses automatically ssh for short files, and scp for large files. If you trust the default method set in tramp-default-method, you ...
Well this turned out to be more of a rabbit hole than I though... And for what I can gather there's not a better solution for this specific issue, with this combination of desktop, ssh-agent, emacs.
XFCE was starting it's own ssh-agent with the session, without actually saying so anywhere, which caused the system to have 1 unused global ssh-agent, ...
auto-revert-tail-mode is great, but it has its limits. Therefore I prefer to use an asynchronous shell command. Open the remote directory in dired, position the cursor to the file you want to watch, and apply ! tail -f * &.
If you want to suppress Tramp messages, decrease the verbosity. (setq tramp-verbose 1) shall be sufficient.
Since TRAMP uses ssh by default, the real question you are asking is if you should use local or remote emacs to edit remote files. Right?
Is it considered better to use ...
There is no better, just that use cases differ for both local and remote editing.
What are some of the considerations involved in making this decision?
If you normally work with ...
Another solution for the lazy is to just use a package that handles exactly this case (setting Emacs' keychain-related environment variables):
Install and add to your init.el package keychain-environment.
Run M-x keychain-refresh-environment and now it should work.
Place (keychain-refresh-environment) in your init.el, so the solution works after restarting ...
There are a few answers here.
Quitting Emacs without C-x C-c
First, you can quit emacs by running the command that C-x C-c is bound to: M-x save-buffers-kill-terminal.
Alternatives to recursive Emacs
Emacs is able to edit files on remote servers, so you don't even need to ssh into the remote server, and you won't need an Emacs inside a term inside your ...
You'll have to customize the tramp-password-prompt-regexp variable with the second prompt to finish the 2-factor authentication. The remote shell setup part of the manual has a simple example.
This is not a new feature but an old feature that you adapt to the second prompt of the 2-factor authentication. This same facility was used in days of yore for ...
As pointed out by @Nsukami and briefly summarized in my comment he linked to, this is not supported out-of-the-box yet. But by following these suggestions you should be able to get it to work.
What I don't understand is, if this doesn't work with when ssh'ing into a remote host, when would setting $EDITOR [to anything but emacsclient] by handy?
Using ssh ...
I would do this outside of Emacs, with a wrapper script that pulls the updated config first.
Something like this:
cd ~/.emacs.d && git pull --rebase
exec /usr/bin/emacs "$@"
Then make this executable, name it emacs, and put it on your PATH before the real one.
Another option would be to have init.el do pretty much the same thing: (call-...
I had a similar problem when trying to open/save plain ASCII files via tramp's sftp: the files were fine, I was able to edit them with, for example,nano, but trying to open them via tramp would get rejected with the rather cryptic message: invalid string format.
This was probably related to inlining and compression, because changing those solved the issue ...
Magit's wiki now features a page about the various ways one can push from Magit when using MS Windows. Also checkout the new ssh-agency package. Both the wiki page and the package were written by @npostavs.
Also note that it is virtually never Magit's fault if you cannot push. It's usually a configuration issue (even if you can push from the shell but not ...
Usually, the problem is that Emacs can't access the password prompt of git on Windows. Thus, it seems to "hang" on push, where it really is waiting for your password. You can circumvent this by using an ssh key instead of a username/password in your git repo, and doing the first push manually in the shell (git will remember your ssh password after the first ...
I agree with Emacs User: Neither approach is objectively "better". If you don't have any obvious compelling reason to go with one or the other, then it's really just a subjective balance between performance and convenience.
If you need only occasional access to any given server, the ease of using TRAMP ought to trump a low-to-moderate performance hit.
Similar to Emacs bug#20015, this can be avoided by setting tramp-ssh-controlmaster-options before loading tramp.
"-o ControlMaster=auto -o ControlPath='tramp.%%C' -o ControlPersist=no")
Or with use-package:
:init (setq tramp-ssh-controlmaster-options
There is Tramp. You can edit a file on another machine using the syntax /ssh:user@machine:/path/to/file. If you take sudo instead of ssh, and empty user and machine, you can edit a local file as root. Like /sudo::/path/to/file.
Running ssh-agent and hoping for the best is not enough. ssh-agent hands out the decrypted private key to everyone asking on a specific socket. The problem is that the socket is not always the same and therefore only those processes that know the currently used socket can benefit.
When ssh-agent is started it outputs the socket and its pid.
I know it's an old question and that you maybe don't care about the answer now but I do faced the same issue.
I was pretty sure it was OS X related but in fact lags and timeouts were caused by my remote prompt!
Tramp is limited in its remote prompt parsing and relies on it to know if a command has finished or not.
I googled for days always including "os x"...
This is common problem, seems to be a bug in Emacs.
Potential solutions are;
turn the number of CPUs down to 1 in virtual box.
force display redraw in isearch (add-hook 'isearch-update-post-hook 'redraw-display)
use this PPA (if you're on ubuntu) ppa:martin-trojer/emacs24-termfix
Here's some references where this issue is also discussed;
That's not an issue, it's a statement of fact. M-x shell isn't a fully functional terminal - it simply can't do what you want it to do. If you want a full terminal emulator in emacs, you have to use M-x ansi-term instead.
Emacs 26 by default switches on double buffering for X servers when it finds the Xdbe header on the build machine. (See Emacs 26 release notes at the GitHub mirror.) Some X servers don’t support this.
Therfore switching off double buffering by adding '(inhibit-double-buffering . t) to your frame parameters might fix this. Safest way is to add it to default-...
I have been struggling to do the same. I found a different route that allowed me to do basically the same thing.
You can open a shell buffer by M-x shell and from there connect to the login node, and then connect to the interactive session by qsub -I. Once you're in the interactive session, start an R session by typing the command R. There, you can do M-x ...
It sounds like you should extend tramp-methods, adding a new method which is similar to the sudo method but uses qsub -I instead. You would then be able to use a multi-hop tramp path to first connect to the head node and then to connect to a compute node.
If you haven't already done so, I would recommend using SSH instead of HTTP as many have recommended to me during my investigation of this. That said, I was able to resolve this issue using the below FAQ:
The missing component (from Github's Git Bash .bashrc script) is that it ...
Starting with Tramp 2.2.13, you will be able to overwrite entries of tramp-methods. In your case, you would do something like
(list (regexp-quote "/ssh:email@example.com:")
'(("-A") ("-l" "%u") ("-p" "%p") ("%c")
Tramp works on the basis of default-directory. If you run a shell in Emacs, and you perform ssh in that shell, the buffers's default-directory is still the local path the shell was started from. You have three options to adapt default-directory:
Start the shell while you are visiting a remote file or directory. The shell doesn't run on your local host, but ...