4

I learned about with-editor in this thread. This is something that I have been looking for a long time.

I tried to use it to modify EDITOR and VISUALfollows:

  • I installed it from MELPA, then I open an ansi-term terminal and ssh to a remote host
  • If I do echo $VISUAL, I get: emacs -nw
  • I then run M-x with-editor-export-editor, and choose VISUAL (the only env variable to which crontab seems to be responsive)
  • If I now do echo $VISUAL, I get:

    sh -c 'echo "WITH-EDITOR: $$ OPEN $0"; sleep 604800 & sleep=$!; trap "kill $sleep; exit 0" USR1; trap "kill $sleep; exit 1" USR2; wait $sleep'
    

so the with-editor seems to have worked in affecting VISUAL, so far so good.

Now, when I try crontab -e right after the above, from this same open terminal, I see that it opens a crontab temp file crontab.XXXXzLgfmw on my local Emacs, but it shows me an empty file, even though it shouldn't be empty.

Also, I see that it says:

"Type C-c C-c to finish, or C-c C-k to cancel"

but running any of those commands hangs up the original terminal on which I issued the crontab -e command (the only way to exit it is to kill the full ansi-term session with kill-buffer). Why doesn't it work? How can I debug the problem?

  • I guess, you've already read this comment – Nsukami _ Dec 29 '14 at 3:30
  • Thanks @Nsukami_ I think you are right, and this is a limitation of the approach. What I don't understand is, if this doesn't work with when ssh'ing into a remote host, when would setting $EDITOR by handy? – Amelio Vazquez-Reina Dec 29 '14 at 18:25
7

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 inside of term/shell isn't the only way to connect to a remote and then run a command there. E.g. you could open a remote directory using Tramp and then use async-shell-command. This does work because this does set the default-directory.

This library was written so that Magit could commit using git commit instead of git commit -m message and so that rebasing would work over Tramp - and nothing else. Why one would want that is explained here. That requires the use of the emacsclient but unfortunately that doesn't work over Tramp. So we needed something like emacsclient but which talks back over stdout instead of a socket. The library's header describes how that is done.

Now, when I try crontab -e right after the above, from this same open terminal, I see that it opens a crontab temp file crontab.XXXXzLgfmw on my local Emacs, but it shows me an empty file, even though it shouldn't be empty.

That's because it is a local file, which does not actually exist yet, when Emacs should open a remote file instead. Neither the remote process which needs to use an editor nor the "sleeping editor" process do know that they "are remote" (all processes are local to the machine they run on). Only the elisp part of with-editor (which consumes the sleeping editor's stdout) can know about that and it does so by consulting default-directory.

Tramp does set that variable, so here it just works. term and shell do not do so, but by using the packages mentioned in the emacs.se answer I linked to above, they presumably can be taught to do so.

I will eventually try out these packages myself and if they do their job I will update with-editor's documentation accordingly and make code adjustments if necessary.

But again with-editor was written for Magit, and that doesn't need these features. I was well aware that this library could be useful outside of Magit, that's why I have implemented it as a separate library which does not depend on anything else in Magit. But some of the features it now contains I originally intended for somebody else to implement outside of with-editor.el. @Silex got all exited about the core functionality and so we ended up implementing these things directly in with-editor, but for the time being I don't intend to implement any features not actually required by Magit itself.

running any of those commands hangs up the original terminal

It doesn't actually hang, it just waits for the "sleeping editor" to return, which it does after a week (sic) or when receiving an appropriate signal. Because the elisp part of with-editor, which is responsible for sending that signal, is unaware that it should send it to a remote process, it instead sends it to the local process with the same pid (which hopefully doesn't exist or at least isn't an important one).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.