I mount an sshfs file system with
% sshfs remote.host.org:/home/jrm /home/mnt/remote.host
then edit a file under this file system with
% emacsclient -n /home/mnt/remote.host/some_file.c.
When I save the file I get the warning
some_file.c has changed since visited or saved. Save anyway? (yes or no)
Other editors don't have this problem. What is causing this? How can I prevent it? Both hosts are running ntp and the times are the same.
TIA.
P.S. I'm aware that I can open the files directly with tramp, but I prefer sshfs assuming I can get rid of this warning every time I try to save a file.
I had this problem and one solution is to just ignore the warnings that the file has changed if you're sure you won't be writing over something important.
I wrote a small minor mode to ignore all file change warnings called modtime-skip-mode
you can find the repo here:
https://github.com/jordonbiondo/modtime-skip-mode
this package is also on Marmalade so if you have that setup you can just
M-x: package-install <enter> modtime-skip-mode <enter>
Related
I have my emacs.d folder located at:
C:\Users\<loggedin_user>\AppData\Roaming\.emacs.d
In this folder, I have my init.el file but it is not being picked up by emacs.
Is there another step I am missing, do I need to set an environment variable or something?
When I enter C-x d ~/ RET I end up at
C:\Users\<loggedin_user>\AppData\Roaming\
If I move the init.el file there, it is still not picked up. I have a deliberate error in the file that is not causing emacs to crash when it is opened.
Most likely you have an old ~/.emacs file somewhere else which Emacs ends up using in preference to the other one.
You probably want to check the value of user-init-file which will tell you which file Emacs ended up using as "the ~/.emacs file".
I suggest you report this as a bug, requesting that when several files are found as possible init file, Emacs should not just pick the first and ignore the others but should at least emit a warning about the fact that it ignored the others.
This is tricky on Windows 10 but I solved since I was suffering from same issue.
I created an Environment Variable called HOME with the path C:/user/<username> in the box "User variables for " create a new one
Just open with double click any file that is by default opened with Emacs and it will take few seconds to load then take changed on the init.el
create an init.el with just one line of code like:set-background-color "honeydew"
to test this, first before doing something more complex.
Hope That It Helps!
On Windows, Emacs is started with some Properties defined, found when you right-click the executable on your windows system. There you can define the
execution-directory, e.g. "C:\Users\loggedin_user\" (in parantheses)
where emacs executes
and looks for the .xemacs (.emacs) directory, where it find its init.el. (I had to create an .emacs File in my Windows Home Directory, which is defined in the Windows HOME Environment)
And where you can define the startup instructions (like (setenv "HOME" "c:/Users/Username/") ) etc.
If you configure that, the next time, emacs starts from the directory, you defined, with the initialisation-file
Windows 10 and Emacs 27.1 could not find .emacs.d: one more possibility, in my case %HOME% was set like HOME=%HOMEDRIVE%%HOMEPATH%. This redirection seems not to work and emacs was using literally C:\Users\<loggedin_user>\%HOMEDRIVE%%HOMEPATH% for searching .emacs.d. I did not dare to edit %HOME% but created link:
C:\Users\username> cd %HOME%
You perhaps need to remove some files in C:\Users\<loggedin_user>\%HOMEDRIVE%%HOMEPATH% which emacs already created.
Create link:
C:\Users\<loggedin_user>\%HOMEDRIVE%%HOMEPATH%> mklink /d .emacs.d ..\.emacs.d
So here is an interesting error...there is a particular folder on my desktop (hdrive, connected to a university-wide backup system, was set up automatically by IT) where emacs has difficulty opening files. In some directories within hdrive emacs can't open files above the current directory. For example,
cd ~/hdrive/directory/
emacs ../another_directory/file
gives the error message
emacs: `get_current_dir_name' failed: No such file or directory
I get the same error if instead I try
emacs ~/hdrive/another_directory/file
The files themselves are not missing and not corrupted, as using cat in place of emacs in these commands works fine. And I don't get this problem with all directories in hdrive - sometimes even a directory with this problem will have a subdirectory without it - but the directories with this problem are consistent.
There is no .dir-locals.el anywhere in hdrive, so that can't be messing things up.
Any ideas?
For me, this problem occurred because I was standing in a folder that I had deleted and recreated in another terminal (git issue).
Navigating away from the folder and back again made emacs and/or the terminal understand which folder I was actually in, and I could start emacs again with no problems.
I doubt this will solve the specific issue the questioner had, but anyone else ending up on this page through a google search on the error message might find my answer useful.
So I've finally decided to learn Lisp. I'm reading Practical Common Lisp and I'm using Lispbox (not the one the book recommends - it's no longer available, but it seems this is suitable nonetheless).
So far in my career I have managed to avoid wresting with emacs, but I guess that part of my life is over :-) Actually, I'm kind of excited - this is a brand new world.
When saving .lisp files, the out-of-the-box setup dumps these files into the lispbox-0.7 folder (which is also the LISPBOX_HOME env.var). My math teacher taught me, "If you don't know what you're doing, at least do it neatly." So I want to at least keep my work in a nice tidy folder. I can specify the full path on saving/loading. But can I tell (lispbox|emacs|whatever) to use a different folder by default?
If it matters: I will likely use the Windows version more often, but I also have a setup on Ubuntu.
I have looked at this and this and this. I tried adding these to the .emacs file (one at a time):
(setq default-directory "C:/Work/lisp/")
(cd "C:/Work/lisp/")
To open the .emacs file I used C-x C-f~/.emacs
If I try changing the LispBox shortcut's "Start in" property, it fails to load at all.
M-xcd c:/work/lisp does work, but I have to do it every time I launch LispBox
What I'm doing in the meantime: I've created a separate lisp folder beside the lispbox-0.7 folder. That way I can prepend ../lisp/ before any filename. This isn't so bad, especially with the tab auto-complete.
Found it!
The reason modifying .emacs wasn't working is because of the lispbox.bat file. It has this line:
%EMACS% --no-init-file --no-site-file --eval=%TO_EVAL%
So took out the two "no" parameters, leaving this...
%EMACS% --eval=%TO_EVAL%
...and it worked.
This worried me, though. Why would the default not want to load the .emacs file? I guess once I understand all of this better I'll have an answer. Until then, I restored the above, the changed this line...
set TO_EVAL="(progn (load \"lispbox\") (slime))"
...to this...
set TO_EVAL="(progn (load \"lispbox\") (slime) (cd \"C:/work/lisp/\"))"
Now I'm happy.
I know nothing about Lisp Box, and not all of what you describe is clear to me. But here goes.
It sounds like you are looking for a way to make c:/work/lisp the default directory when you start Emacs. For that, using an MS Windows shortcut, putting that folder in the Start in field does indeed accomplish that. But you speak of a LispBox shortcut's Start in. If by that you just mean an Emacs shortcut, then it should work.
But of course you need to use Windows syntax for the folder - not c:/work/lisp, but c:\work\lisp.
Is that what the problem was?
The Windows shortcut is a Windows thing. Emacs is different: it accepts / as a folder separator.
Tip: If that solves your problem, you might also want to start Emacs in Dired mode on that same folder, that is, if that folder is the one you will use a lot. To do that, add that folder at the end of the command line - again, using Windows syntax, but between double-quotes:
c:\your\path\to\runemacs.exe "c:\work\lisp"
Try starting lispbox.bat from the directory you want to save files to. For example, from the OS command prompt:
cd c:\work\lisp
path-to-bat-file\lispbox.bat
You can also cd to c:\work\lisp in listbox.bat before it executes Emacs. For Linux it looks like this in lispbox.sh:
#!/bin/bash
if [ "${0:0:2}" = "./" ]; then
export LISPBOX_HOME=`pwd`/../../..
else
export LISPBOX_HOME=`dirname $0`/../../..
fi
cd ~/work/lisp
export SBCL_HOME=${LISPBOX_HOME}/sbcl-1.0.42/lib/sbcl
exec ${LISPBOX_HOME}/Emacs.app/Contents/MacOS/Emacs --no-init-file --no-site-file --eval='(progn (load "lispbox") (slime))'
Normally I am able to use tramp just fine to edit files and browse through the remote file system through SSH. Though at seemingly random times I would lose the ability to browse remote folders in emacs.
I get the error message:
Wrong type argument: number-or-marker-p, //DIRED-OPTIONS//
I've tried doing a clean reinstall of emacs without any customizations and the error still happens.
Also sometimes the error happens after browsing 1 or 2 directories while other times I'm able to do five or six directories before the error will appear.
Edit:
I'm using Emacs 23.3 running on OS X 10.6.8
Edit 2:
While I'm still going through the tramp debug log A couple of other pieces of information.
After the error I'm still able to use tramp of open and save files, just not view directory listings.
It seems to happen only when I save to a directory that is version controlled using git.
In the debug log the directory contents are listed out but it is not being outputted to the user
The directory listing inside the debug log show ^M (I usually notice this in the emacs info bar when editing files that have been versioned in git) even when I try to access a non-version controlled directory
The message is useless by itself. You should try to obtain more traces on the tramp behavior in order to find where is the issue. See the Traces and Profiles Section of the TRAMP User Manual.
Sorry to not help more but with another release on another platform…
Update:
Put the following in your emacs file
(require 'tramp)
(setq tramp-verbose 10)
(setq tramp-debug-buffer t)
Then, use tramp. Now, You should have a *debug tramp/method hostname* buffer.
I found out that this happens when I enable:
(setq-default dired-omit-mode t)
But for now I don't know how to make it work with this mode
After opening a file in emacs (over an ssh tunneled, sshfs mounted file system) I get symbolic links like this:
.#jobid.php -> ddh#localhost.localdomain.31678:1260471633
We have determined that these are emacs LOCK files.
The sshfs filessystem is mounted with follow_symlinks and transform_symlinks, but it appears to be refusing to return the link 'text' via readlink so emacs is not removing them.
In case you're looking for documentation, Emacs refers to these files as file locks.
Instead of using sshfs/FUSE, you can access remote files directly from Emacs:
C-x C-f /ssh:host.name:/path/to/file RET
Emacs doesn't create file locks when editing remote files in this manner-- search for "TRAMP" for more info about editing remote files. (Unfortunately, I guess Emacs can't tell that your FUSE mountpoint is backed by a remote filesystem or that creating file locks on it is problematic.)
Those symlinks are used by emacs to prevent multiple emacs instances from modifying the same file. The symlink normally goes away when you save the file, but it sounds like fuse-sshfs is interfering with this process since the target of the symlink isn't a real file (it isn't meant to be, but sshfs expects it).
Unfortunately, I don't know of a way to disable this feature or force emacs to store these symlinks in a different directory (I use emacs infrequently and I didn't find anything in the manual), so you may have to just periodically delete them manually I'm afraid.
The follow_symlinks option forces symlinks on the remote system to appear as actual files. This is useful when the symlink refers to a target on the remote host outside the directory that is mounted via sshfs, but it breaks Emacs's assumptions because when Emacs creates a symlink, it expects that same path to look like a symlink later.
However, you should be able to make all symlinks on the remote host work correctly while still appearing as symlinks by using the transform_symlinks option (and not follow_symlinks) and always mounting the root of the remote system (instead of just your home directory or something). This should allow emacs to abuse symlinks as lockfiles while still making remote symlink targets accessible.
These symlinks are created by Emacs when a buffer is visiting a file, and they prevent two Emacs instances from editing the same file (as mentioned in other answers). Emacs refers to this as "clash detection".
Unfortunately, the only way to prevent this behavior in GNU emacs is at compile time. The source docs describe how to do this by changing a header.
This is because the lock-buffer and unlock-buffer functions are primitives, and are called by other primitives to create these symlinks. In older versions of Emacs, they can be redefined or defaliased in elisp, but a primitive will not notice this change.