[NOTE] this answer was heavily edited to follow the updates of with-editor developments. Most comments likely won't make much sense anymore. There are some new comments which do make sense.
Magit contains a library named with-editor available at https://github.com/magit/with-editor which allows you
to use your local Emacs as an $EDITOR on remote machines ...
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 ...
Turns out it was projectile that was causing the problems. As soon as I disabled projectile-mode TRAMP was buttery smooth and I began to understand the hype behind it.
Hopefully this helps out someone else who has exhausted all other options.
Another solution I found if you don't want to disable projectile constantly is to put this command in your init.el
That looks like a bug in eshell, you should report it.
I think you can fix it by
(defadvice eshell-gather-process-output (before absolute-cmd (command args) act)
(setq command (file-truename command)))
Bottom-line, the problem is that tramp ends up constructing a remote command line of the form (I'm removing some escaping to make it clearer):
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.
This cannot be done without some changes to mosh.
Unlike ssh, mosh doesn't transmit every character that is sent by the application — it will happily skip sending data that has already scrolled off-screen, and will omit data that has been overwritten by later screen updates over high-RTT links. Therefore, it cannot be easily used for automation.
There has ...
Here's a really quick and dirty solution:
(defun my-view-source (url)
(interactive "MURL: ")
(switch-to-buffer (url-retrieve url (lambda (_)))))
url-retrieve is built-in to Emacs; there are also alternatives such as request.el.
The "problem" is that with M-x shell (or M-x eshell btw), Emacs uses a very limited terminal emulator, so that TERM is correctly set to dumb
Fancy pagers cannot operate under such limited constraints, which is why you have to use cat instead.
Now, when you open an ssh connection from that shell, TERM is still dumb, but PAGER is reset to whatever the other ...
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 ...
I use a simple password manager called pass. It offers a simple command line interface with is ideal for integrating with Emacs. The backing store is a GPG encrypted GIT repo. It actually ships with an Emacs package although I don't use it. My interface is laughably simple:
(defun my-fixup-gpg-agent (frame)
"Tweak DISPLAY and GPG_TTY environment variables ...
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 think one of the things unclear from the FAQ is the necessity that both server and client be resolveable from each other. You can see this thread from 2009. Eventually, back then I did get it to work, but now I do see the same as the OP. This is what I tried:
(setq server-name "sx-test" ; name of the server
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 ...
I had this exact same problem but it had nothing to do with RVM on ( which I also have ) on my Ubuntu-16.10 machine. It was related to by custom prompt (PS1)
The issue was the prompt PS1.
This fix : https://stackoverflow.com/questions/6954479/emacs-tramp-doesnt-work
Essentially in your .bashrc
case "$TERM" in
You could change the .bashrc such that it doesn't modify the prompt when the TERM variable is set to "dumb".
if test $TERM = "dumb"
# leave the prompt alone
# set up fancy prompt
According to the manual TERM is governed by tramp-terminal-type, which defaults to dumb.
Like @lawlist said, determining if a file or directory is remote is easy and can be done using file-remote-p which will actually return the remote host is available.
You could then use find-file-hook and dired-mode-hook to check if the file is remote and if so assign the host a color(s) and use that color to determine the mode-line and mode-line-inactive ...
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
Emacs knows two basic commands for running external processes, call-process for synchronous processes, and start-process for asynchronous processes. For the remote case, these commands have been extended as process-file and start-file-process.
Remote synchronous processes use always the same ssh connection Tramp uses for its internal commands. Asynchronous ...
I don't have that problem, using find-tag over TRAMP resolves the filenames over TRAMP as well.
That said, that works only if the TAGS file contains relative paths (relative to the location of the TAGS file itself, therefore over TRAMP), and not absolute ones.
I guess it'd be better if in case of absolute filenames over TRAMP, the resolution was smart ...
What about writing a "safe" version of shell-command that would properly escape arguments using shell-quote-argument ?
(defun safe-shell-command (args &optional output-buffer error-buffer)
(apply 'shell-command (mapconcat 'shell-quote-argument args " ")
output-buffer error-buffer nil))
(the same would easily apply to async-...
This question has been already answered by rekado (thanks!) (as a reply to another more general question about eshell):
You can configure TRAMP to respect the PATH variable on the remote
machine (for remote eshell sessions) by adding
'tramp-own-remote-path to the list 'tramp-remote-path:
(add-to-list 'tramp-remote-path 'tramp-own-remote-path)
In addition to the Tramp manual, there's a full manual for auth-source.el: (info "auth") that I wrote, which may help you. In the case of SSH logins, you may find it better to avoid passwords altogether--look at SSH keys instead.
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.