When I open the file zenburn-theme.el from github.com/bbatsov/zenburn-emacs.git in Emacs 24.3, I get the following warning in a buffer:
Why? Also, why would it not be safe to open (not load or run) a file?
A file, even if opened and not loaded, might contain some configuration values to be applied. Some of them are considered unsafe and Emacs asks you about them unless told otherwise. See Local Variables in Files for details.
Related
A directory titled auto-save-list appeared in my .emacs.d folder. In my init.el file, I did not explicitly mention I want this folder to be made. What is the purpose of this folder? I noticed it seems to always be empty: files being auto-saved (starting with #) appear wherever the original file being edited is, not in the auto-save-list directory.
If you search the manual or its index for auto-save-list you will find:
Emacs records information about interrupted sessions in files named
‘.saves-PID-HOSTNAME’ in the directory ‘~/.emacs.d/auto-save-list/’.
This directory is determined by the variable
‘auto-save-list-file-prefix’. If you set ‘auto-save-list-file-prefix’
to ‘nil’, sessions are not recorded for recovery.
– C-hig (emacs)Recover RET
I did not explicitly mention I want this folder to be made.
Emacs and elisp libraries in general write to ~/.emacs.d/ when they need to save data. That's one of the purposes of this directory -- to provide a common place for such files to be written to; and this typically happens without asking explicit permission (although it's also pretty common for you to be able to customize the filename in question if you so wish).
phils already answered the specific question, but to answer the more general question of what to do about miscellaneous files automatically created by Emacs, check out the no-littering package.
Auto save files (the ones with '#') are not handled by no-littering, but the readme gives a work around for those if you wish.
Background:
I modularised the init.el file into several files and tried to load them one by one from init.el.
Each file has a:
(provide 'xxx)
at the end and I use:
(require 'xxx)
to load them.
(before I used load-library to load them, but recent I learned the require command will only load them if they are not loaded.)
Then some wired behaviour appears.
I'm not sure if this is the problem of not loading the library in the right order or of not loading certain file.
So the question is:
How can I see which file are loaded by the require command? (In the 'Message' buffer, I can see files loaded by 'load-libarry', but not by 'require')
You might inspect the variable load-history.
You could look at featurep function and features variable: each time a provide statement is encountered, the features variable is updated.
How can I check the identity of someone who has created a buffer in Emacs and then later on check whether is the same user accessing that buffer? I mean something like "Who Am I?" in Unix command.. and then check if the same user is accessing that document? --> I want a function or a way to this in my own code
Note the difference between a buffer and a file: A file is something that sits on your hard disk, such as a .jpg image file or a .mp3 aufio file or a .txt file. Some of those files - typically text files - you might want to edit with Emacs. To do so, you can load the file into Emacs - this is called "visiting" a file in Emacs lingo. The contents of the file are displayed in a buffer. But note that you could also have a buffer that is not associated with a file at all - for instance the *scratch* buffer that gets displayed if you start up Emacs without specifying a file.
Thus files and buffers are pretty much orthogonal concepts, although often times you create buffers by visiting a file, and you save the contents of a buffer by writing to a file. (You can create a buffer that is not associated with a file by typing C-x b buffer-name where buffer-name is an identifier not used by any of the already existing buffers.)
A buffer exists only inside a running Emacs. This is why the comments and answers you have gotten so far may not have been what you're looking for: the notion of the creator/owner of the buffer is confusing, because it is obviously the person who's sitting at the keyboard at that particular moment.
Speaking of the owner/creator of a file makes much more sense. In a multi-account setup, more than one user can write to the same disk, and so they might have access to the same files. Now it can be interesting to know who has access, and in particular who owns the file or when it was last modified. In Elisp, you can use the function
(file-attributes FILENAME &optional ID-FORMAT)
to get a list of attributes associated with the file. If your current buffer is visiting a file at all, you can combine that function with the function
(buffer-file-name &optional BUFFER)
which returns the file the buffer is visiting. For a buffer that is not visiting a file, this function returns nil.
Note, however, that some information you might be interested in is not available through (file-attributes ...), such as who last accessed the file and/or who last modified it. This is not so much Emacs' fault, but comes from the fact that the operating system does not store such information.
Also note that the current owner of a file might not necessarily be the person who created it as someone with the required privileges can chown a file after its creation.
To receive information about the current user in the sense of whoami, you can check out the variables
user-login-name
user-real-login-name
user-full-name
by typing C-h v variable-name.
AFAIK seen from system, Emacs is a single process, owned by the user who started it
(getenv "USER")
is the respective to
echo $USER
I have a project, call it 'foobar', that when I checkout has all its source in the folder "foobar/foobar". Because the top level foobar directory contains nothing except for the inner foobar directory, it's pointless, but that's how things were originally checked into the project and it's outside my control. This has the unfortunate effect of making paths longer and harder to read, so I rename the toplevel foobar to "foobar-checkout" and then make a symlink called "foobar" that links to "foobar-checkout/foobar". This way I can open "foobar/source.c" instead of "foobar/foobar/source.c".
This works for when I'm in the shell, and when I first open the file in emacs, but after that emacs will resolve the symlink. So if I have source.c open and I press Ctrl+x Ctrl+f to open a new file, the path it lists is "foobar-checkout/foobar/" rather than "foobar/". Is there a way to get emacs to not resolve the symlink so I can enjoy the shorter path?
I've just tried this on GNU Emacs 22.2.1, and it doesn't seem to resolve my symlinks. Is it possible that the resolving of symlinks is not vanilla emacs behavior and is rather something unintentionally introduced with a file opening module, such as ffap.el?
Either way, I couldn't test my idea, but it occured to me that you might override file-symlink-p, described currently as:
file-symlink-p is a built-in function in `C source code'.
(file-symlink-p FILENAME)
Return non-nil if file FILENAME is the name of a symbolic link.
The value is the link target, as a string.
Otherwise it returns nil.
This function returns t when given the name of a symlink that
points to a nonexistent file.
If you modify that to always return nil, perhaps emacs won't resolve the symlinks:
(defun file-symlink-p (FILENAME)
nil)
Of course, this will probably break some other stuff, but maybe it's worth a shot.
You might like to use directory-abbrev-alist or maybe vc-follow-symlinks.
I have Emacs open but accidentally I've deleted the .emacs file it read when it started. This represents about 15 years of tweaking. (I know, I know, backups.)
Is there a way to get Emacs to write out the .emacs file I've deleted?
I wouldn't normally ask such a lame question on SO but I know I only have a day or so before this Emacs session ends.
As ayckoster suggests, you might try a file recovery or forensics tool like The Sleuth Kit. Or, and this may seem crazy, if you're on a Unix-like system, you could search through the raw disk device (on the Mac I'm currently on, that would be /dev/rdisk1). Seriously, several times I've been too lazy to break out a full-blown recovery tool but instead used something like sudo less -f /dev/rdisk1, searched for a string I knew was in the file (global-set-key, anyone?), and succeeded in recovering the file's original content.
If you have Emacs' backup feature turned on, you should have a copy of your next-to-last .emacs file in ~/.emacs~. If so, just rename that one to ".emacs" and you will have the .emacs file with all but your latest changes. Even if you don't currently have backups enabled, you might still have a substantial chunk of your .emacs file in the last backup on file. You should also look at the value of the variable "backup-directory-alist" - it specifies location(s) for backup files to be stored if the default (same directory as modified file) isn't used.
Otherwise, how good is your memory... ;-)
EDIT: Since you don't have a backup of your .emacs file but you have a running Emacs instance that was started with that .emacs file, another thing you can do is to save all the custom settings that would have been defined in your .emacs file. To do this, do something like:
(setq custom-file "/my/home/directory/.emacs-custom.el")
(custom-save-all)
Then, you could create a new .emacs file and add the following lines to it:
(setq custom-file "/my/home/directory/.emacs-custom.el")
(load custom-file)
That will at least restore some of the custom variable settings that were in your .emacs file.
Emacs evaluates your .emacs file and afterwards it is closed. So basically you cannot get your .emacs back.
A solution might be to use a file recovery application. The odds of your .emacs being on your hard drive are quite good.
As most such programs cannot deduce the file name or directory name of the deleted file you have to know the content of your .emacs.
Then you can restore all currently deleted files in some folder and recursively search for the contents of your .emacs.
This process might take very long. You have to decide if its worth your effort.
I don't know of any way to get Emacs to provide the original .emacs file, but you can certainly interrogate the loaded function and variable symbols, and obtain their values.
This would be rather a lot of work, but I think in theory you should be able to obtain a good chunk of this data in some form or other, if you succeeded in filtering it all down to what you knew was yours.
For evaluated functions, (symbol-function 'SYMBOL) will return a (less-readable) definition of the supplied function. You could then use (fset 'SYMBOL VALUE), where VALUE is the result of the call to symbol-function, to define that function in a new .emacs file. That would give you an approach for recovering your defined functions.
http://www.gnu.org/s/emacs/manual/html_node/elisp/Function-Cells.html
http://www.gnu.org/s/emacs/manual/html_node/elisp/Symbol-Components.html
You might also look at:
How to print all the defined variables in emacs?
This is a very incomplete starter, but given time constraints I'm posting and marking it community wiki, if anyone wants to run with it.
A how-to for dumping the state of the application in a reliably restorable fashion would be a great start, if the current session is definitely going to be killed (or even if it's not, actually, to guard against crashing or other mishap).
You could potentially re-tag this with some more general data-recovery type tags, to expand the audience.