Whenever I try to save my emacs file, it prompts me "file has changed since visited or saved. Save anyway? (yes/no)". I tried "diff buffer-with-file" but it says there's no difference. I'm suspecting this is happening because I'm using a virtual machine with shared file. Anyway, I want to silence this error, and save without prompt. Any solutions?
If this is only happening for a particular file in a particular Emacs instance, you can try M-x revert-buffer to replace the buffer with the contents of the file. That should reset the timer to what's on disk. Of course you will lose any unsaved changes, but you say you have none.
If this doesn't work, or you are getting this error for every file every time you run Emacs, you are in bigger trouble than I know how to diagnose.
Related
Which is the final outcome of the VScode [issue] #14298 (https://github.com/microsoft/vscode/issues/14298) ?
Is it: "No, we will NOT issue a warning, if an external app modifies a VScode opened file, like ALL other editors do ? (except Notepad)"
Up to now, I cannot find such a setting...
I have never seen a prompt when an open file is changed elsewhere. What I have seen is a warning when I try to save a file that has been changed elsewhere. I have seen this: preventing dirty writes
VS Code will show you an error message when you try to save a file
that cannot be saved because it has changed on disk. VS Code blocks
saving the file to prevent overwriting changes that have been made
outside of the editor.
In order to resolve the save conflict, click the Compare action in the
error message to open a diff editor that will show you the contents of
the file on disk (to the left) compared to the contents in VS Code (on
the right):
Until those issues have been resolved I believe that is as close as you are going to get.
This is what I am doing:
Make a file or use an existing file.
Emacs filename.txt.
Type some new text into the file.
Save file.
After step 2, I receive an error after the emacs editor window pops up.
Here is the error:
2022-01-19 22:11:53.935 Emacs-x86_64-10_14[33893:994906] It's not
legal to call -layoutSubtreeIfNeeded on a view which is already being
laid out. If you are implementing the view's -layout method, you can
call -[super layout] instead. Break on void
_NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
I have already tried updating emacs and that didn't help, and googling didn't give me an answer. Currently, I have GNU Emacs 27.1 version.
How do I fix this error?
As far as I know you shouldn't need to "fix" the error at all and it won't cause any problems while you're actually running Emacs. In fact I'm somewhat surprised you see it at all.
I was only able to see the error (in both Emacs 27 and in pretest-28.0.90) only by running the Emacs binary (eg. ./Emacs-27.app/Contents/MacOS/Emacs) directly from a terminal, which isn't the normal way of starting Emacs on macOS. If you just run Emacs by starting it from Finder, the Dock, or via the "open" utility then you shouldn't see the error at all, and it shouldn't cause any problems.
The whole point of keyboard interaction (and emacs in particular) is that there's no need to touch the mouse. It's possible to log in (using e.g. ssh) and edit remotely, with no gui (so no way to drag and drop), and this is the 'normal' way of invoking emacs. Run 'emacs --help' from the command line to see a bunch of options. In particular see 'emacs --no-window-system' which uses a raw terminal even when a gui is available (no error message appears when it's run this way).
The gui however adds font and image support, which can be useful if you're sitting at the machine. The error message you get when you invoke 'emacs' from the command line in its default mode, with no arguments, is a diagnostic describing a bug in the mac gui implementation.
The error's still there if you start emacs through the finder; you can see that by running (e.g.)
$ open /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
which both opens an emacs gui and a terminal window containing the program's text output.
As it says in the message, 'this may break in the future'; it's not helpful to say 'you're using it wrong.'
This section of the emacs manual states that revisiting a file is the default way to load tags from the semanticdb, but (in the second paragraph) that it's possible to access the tag information without opening that file again. Does it require another program hooking into the API mentioned or are there built-in settings? I thought maybe the search-throttle setting would do it, but doesn't seem to help. If it does require another program, does such an app exist?
For example, if I open foo.cpp and foo.h, I can use semantic-analyze-proto-impl-toggle to jump back and forth between definition/implementation. When I close emacs, I can investigate the contents of ~/.emacs.d/semanticdb/ and ensure the tags from foo.cpp were saved.
Then, open foo.h in a new emacs session and try to jump to the implementation of a definition. Until I open foo.cpp in a buffer, I'll get the "Could not find suitable implementation" message.
I want it to work right away. If the file isn't opened I think emacs should just load it into a new buffer and take me there!
I'm talking specifically about Pymacs, but this would be useful to know if anything like that happens in other circumstances.
The problem: when something goes wrong in Pymacs, it will no matter what try to restart itself, and especially so when it fails to start at all. But somehow it is adding a hook to run before any file (not necessary in Python mode) should be saved or closed. So, what happens - it becomes impossible to shut down Emacs in a "nice" way - I can only terminate the process from shell, because Pymacs would enter an infinite loop: when saving a file - it would try to restart itself, fail and prevent the file from being saved - since it failed, it'll prompt to restart - no matter if I answer yes or no to restarting it, it will fail and ask again to restart itself.
M-x unload-feature doesn't help because it can't unload it (because .emacs loads it). I'm not sure at all by the way if the unload-feature can ever do anything meaningful :| I was trying to evaluate (setq kill-buffer-hook nil) but this didn't seem to help either. Perhaps there are some other hooks? Is there a way to force unload-feature to actually do something? In this situation I'd prefer save file and crash, then infinite loop and no crash, but file not saved situation.
Recently I have been having an issue with desktop save mode where it will not actually save my desktop. In the echo bar it says "Error while saving the desktop..." After typing no it says "Opening output file: no such file or directory, then gives the location to the path of the file". After saving a .emacs.desktop file then restarting emacs I noticed that it is saving the buffer locations in that file but is not loading that file. Thanks. Also I am not sure what has caused this to happen as it was working a couple weeks backs and nothing has changed that should make a difference.
The only thing i have in my .emacs for the desktop mode is
(desktop-save-mode 1)
Looking at the code for desktop.el here, it looks like the error is bubbling up from desktop-kill, which runs when you exit Emacs. The first thing I'd try is to check that the directory where it tries to save the desktop is sane.
Looking at the code in desktop-kill, it only tries to do anything if the variable desktop-dirname is non-nil. But that only gets set when you run M-x desktop-save for the first time: are you sure that it's set to something sensible? To check its value quickly, you can type M-: desktop-dirname RET and it should appear as a string in the message area.
If the directory is something sensible (the directory exists and you can write to it...), then I'm not sure. You'll probably have to give more information to get a solution, and it's not really clear that it's an ideal question for StackOverflow.
i should hazard that you get this error by creating a shortcut in the windows start manual via clicking addpm.exe in the ...\emacs-version\bin\ folder.
you can further modify the shortcut. go to its property->shortcut tab, you will find that the Target has value like ...\emacs-version\bin\runemacs.exe, while Start in is void. try to fill Start in with the corresponding folder ...\emacs-version\bin (actually most directories would be fine, just don't leave it blank), then everything is fine. still, the machanism behind this remains unclear to me.
or you could always creat your own shortcut manually, only make sure that the target is runemacs.exe, not any other exe file.