I'm currently using this template
(setq org-capture-templates
`(("e" "ethz studies tasks"
entry (file+function ,(concat org-directory "/ethz-tasks.org") (lambda ()
(print (f-filename default-directory))
(search-forward (f-filename default-directory))
(move-end-of-line)
(newline)))
"** TODO %t [[file:%F][%f]]\n%?\n")))
In an attempt to get the template to file a little todo note about the current file, under a heading which is the name of that files parent directory
i.e.
* directory
** TODO <date> [[file:...][file]]
some extra info
The problem with my current snippet is that it uses default-directory, which in the context of the capture, seems to be "org". I want to get the name of the directory I was in before invoking the capture.
Which function should I be using for this ?
Is there maybe some easier way to do this in org capture than the way I'm going about it ?
org-capture stores bits and pieces of information in a dynamically-scoped variable org-capture-plist. Once the capture process starts and creates the capture buffer, the global value is copied to a local buffer variable org-capture-current-plist. This is where the values for all the formats in the template are stored and are fetched from (%f, %F, etc).
I have not tested any of this, so you might have to adjust according to what you find out, but I believe that you will need to query the local variable (although if you find that's nil, then you can try querying the global one). In either case, the original pathname is stored under the property :original-file, which you can get using
(org-capture-get :original-file t) ; query the local plist
OR
(org-capture-get :original-file) ; query the global plist
depending on which plist you want to query. You can then get the directory name by calling file-name-directory on the result.
One or the other of these should give you the directory which you can then use as a heading. I'm not sure though whether the heading needs to exist already: if it has to exist beforehand, then you must do additional work, work that is not covered by this answer.
Completely and utterly untested, if that's not clear already.
EDIT: Here's a slightly more detailed explanation of the global vs local plist.
When you call org-capture, the various values are saved on the global plist, then eventually a capture buffer is created and the values are copied to the buffer-local plist. At that point, the capture buffer is waiting for input, so you can initiate a different capture: that goes through the same process, so now the global plist has the information for the second capture (until its buffer is created etc).
So it really depends at what point in the sequence you try to access the value you want: if it happens before the capture buffer is created (as it seems to in your case), then you get it out of the global plist; but if it happens afterwards, you have to get it off the local plist, because the global one may be referring to a different capture.
So you should probably be doing something like this:
(let ((path (file-name-directory
(or (org-capture-get :original-file t)
(org-capture-get :original-file)))))
...
i.e. try to get it off the local plist first and fall back to the global plist only if the local one is nil. That way, you avoid the problem of getting the value from the wrong capture context.
I hope that clarifies the situation.
Related
I have a folder /var/~/. In config .emacs I wanna load some files from this folder.
I try to use (load-file "/var/~/foobar.el"), but emacs alerts File error: Cannot open load file, ~/foobar.el.
Furthermore I couldn't even open the files under this folder with c-x c-f. In minibuffer the path will auto be redirected to my home.
How could I load files in that folder?
You need to rename your directory.
load-file is a simple wrapper around load, which passes the given file name through substitute-in-file-name. From the docstring of substitute-in-file-name (emphasis mine):
Substitute environment variables referred to in FILENAME. `$FOO' where FOO is an environment variable name means to substitute
the value of that variable. The variable name should be terminated
with a character not a letter, digit or underscore; otherwise, enclose
the entire variable name in braces.
If `/~' appears, all of FILENAME through that `/' is discarded. If `//' appears, everything up to and including the first of those `/' is discarded.
In other words, substitute-in-file-name throws away everything before /~, turning /var/~/foo.el into ~/foo.el.
I completely fail to see any reason in this behaviour, but it is what it is, and you cannot (easily) work around it, so renaming is your best way out of this dilemma.
It's a reasonable thing to do, anyway. Using ~ as directory name is bad idea on Unix systems generally, not just for Emacs alone.
lunaryorn explained your problem well, and I agree with his suggestion that not using ~ in file paths is the best solution. However, If you can't rename these paths for whatever reason, I believe you can work around substitute-in-file-name by loading a relative file path as documented here.
Basically, you need to add nil to your load-path variable, then set your default-directory variable to the troublesome path, finally then load the file using a relative name. e.g.:
; adding nil causes load to also search your 'default-directory'
(setq load-path (append '(nil) load-path))
(setq default-directory "/tmp/~/")
(load "foobar.el")
Note that if you suspect the file name might exist (be loaded from) elsewhere in your load-path you would need to ensure the file you want is first in the load-path.
See How programs do loading.
I have files in some location:
location_a/doc.tex
location_a/doc.cls
...
I want to work on them in another directory via symbolic links:
work_directory/doc.tex -> location_a/doc.tex
work_directory/doc.cls -> location_a/doc.cls
work_directory/doc.pdf
work_directory/doc.log
...
However, when I run emacs doc.tex in the work directory and do some editing, emacs creates a backup file at location_a/doc.tex~. I want the backup file to be stored in the work directory, though. I don't want any new files created in location_a.
How can I make emacs do that?
This is trickier than it seems it should be because backup-buffer insists on chasing the links of the buffer file name before calling any backup file name construction machinery, such as make-backup-file-name-function. The result is that Emacs allows no way to customize this behavior, short of redefining backup-buffer, which is a fairly complicated piece of code.
A compromise solution I came up with is to install an "advice" around backup-buffer that temporarily disables file-chase-links while backup-buffer is being evaluated. This allows the backup file to be in the directory where the symlink resides. However, it also causes Emacs to create the backup by renaming the original symlink, leaving one with work_directory/doc.tex~ being a symlink that points to location_a/doc.tex! Fortunately, this is easy to prevent by setting backup-by-copying to t.
Here is the code. A word of warning: while I have tried it to verify that it works, I cannot guarantee that it will not have an undesirable side effect, like the above interference with the backup mechanism that required backup-by-copying. However, it might also work just fine - just be careful when using it.
(require 'cl) ; for flet
(defadvice backup-buffer (around disable-chase-links)
(flet ((file-chase-links (file) file))
ad-do-it))
(ad-activate 'backup-buffer)
For the fun of it, let me describe a radically different approach, based on directory variables.
In short, you would put in your work-directory/ a file named .dir-locals.el containing:
((nil . ((eval . (set (make-local-variable 'backup-directory-alist)
(list (cons "."
(file-relative-name
(file-name-directory (buffer-file-name))
(file-name-directory (file-truename
(buffer-file-name)))))))))))
What this does is abusing somewhat the backup-directory-alist, and install a local version
of it for all your files in work-directory/. That local version will in turn make sure that any backup file is kept within work-directory.
In order to achieve that, we need 2 things:
have something like '(("." . "path/to/work-directory/")) as the local value
make sure this path is relative to location_a/
The reason for the second point is that as noted elsewhere, the starting point of backup-buffer is indeed the location of the actual file, once symlinks are resolved. And we can't simply put the absolute path without having backup files changing shape (in case of absolute path for the backup directory, the backup filenames encode the complete path, so that there is no collision)
Notes:
you'll need to make sure that specific local variable is recorded in the safe-local-variable-values. Since it's a generic form, it's a one time job though (just hit "!" the first time you're asked about it)
this assumes find-file-visit-truename is set to nil, but I guess you wouldn't ask that question if that was not the case :)
Pros of the approach:
no need for advice (which is always a good thing)
reasonably portable although it assumes your Emacs supports directory variables
you keep the flexibility to put that in place only where you need it
Cons of the approach:
well, obviously you might have to copy that .dir-locals.el in several places
Also note that if you wanted a one-shot approach, you could make it much simpler, such as:
((nil . ((backup-directory-alist (("." . "../path/to/work-directory"))))))
where you actually compute the relative name yourself, once and for all.
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'm doing completing-read with a list of filesystem paths, eg. ("~/parent/child" "/parent/child").
I would like to mask the output of completing-read/ido-completing-read so that it would show only child, but would still return the compelete path.
Is this possible at all?
Best regards, Rat
Answer: no, it is not possible, because completing-read does not keep into account any semantics of the strings.
This is possible, but with multiple calls of completing-list.
The idea is that this function is passed a list of strings, and it helps you chose a string from that list.
Completing-list has no control over what the strings contain. It does not care about the semantics of strings, as paths. It sees only list of strings.
So, in order to make how you want, you call it once with the list of files from the current directory, and if you select a directory, first you change tto that directory, and then you call it once again with the list of files from that directory, etc.
If you want to keep pwd the same as initial, then when it returns , you change again to the original dir.
(cd (concat default-directory
(completing-read "> " (directory-files default-directory ))))
The package uniquify does something similar to what you want. When you have two buffers visiting files with the same filename it will add a string at then end to differentiate the two.
For example if you have files /etc/foo/bar/a and /mnt/a it will call the buffers something like a <bar> and a <mnt>. Then when you use ido to switch buffers you do not have to select from the full filename but you end up in the right buffer.
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.