I know you can navigate the contents of an archive with emacs. Is there a way you can edit those files in place and write the archive transparently?. Currently, I navigate into the archive, write the file to a temp directory, and the use the java jar command to add the file back into the archive. Its a little bit of pain.
P.S. I know there are few use cases where you'd want to do this, but I've inherited a platform that I can't readily modify where I have to cope with this limitation in the short term.
Yes, it just works. Did you try it?
I grabbed a jar file that contained a text file and some java code that would print it out. I edited the txt file within the .jar and saved the text file. It did exactly what I would expect.
EDIT- When saving the archive make sure you use C-x C-s
In emacs-23.2 (not 23.1 or 23.3) this doesn't "just work" on Windows due to a bug. Instead it just writes caution: filename not matched: "<internal path>.
One solution is to simply upgrade to 23.3.
To fix the bug in emacs-23.2, open $EMACS_HOME/lisp/arc-mode.el and replace:
(if (equal (car archive-zip-extract) "unzip")
(shell-quote-argument name)
name)
with:
name
and recompile:
M-x byte-compile-file $EMACS_HOME/lisp/arc-mode.el
This answer comes from the original emacs bug report.
Related
When I bookmark a File in emacs, it has the full-path C:/WindowPath/CommanPath/File I can access the same directory from Linux with /LinuxPath/CommanPath/File. But, when I try to bookmark in one OS and access in other OS, the file-path are different and I cannot access the same file from M-x list-bookmark interface. How I can resolve this? Please note that the 'CommanPath' is same for both OS.
Is there something in bookmark library that I can use? If that is not the case, then how should I create shortcuts so it can work seamlessly in both OS, or for that matter in any path ?
Thanks.
Hm. How does Emacs find the same file starting with different absolute file names on different OS's? If you can track that down then you can likely make the bookmark code do the same thing. The bookmark just saves the absolute file name in the form of the OS you were using at the time you created the bookmark. Giving that to Emacs to find should be no different from giving it to find-file, which you say works.
(That is, I think that's what you're saying: you can type the Windows form of the file name at C-x C-f when on Linux and it just works, and vice versa.)
The basic file-finding function is find-file-noselect, but all it seems to do in this regard is (abbreviate-file-name (expand-file-name FILENAME)), which would not be sufficient if given FILENAME as an absolute name from the wrong file system.
If you cannot figure out how to code this generally, you might be able to use directory-abbrev-alist to make your own explicit correspondence between the two directory prefixes. Dunno.
Interesting question.
How do I set up cscope in Emacs when my source code lives in multiple directories?
Say I have several paths for my C++ project:
/path/to/my/code (and subdirectories)
/path/to/other/code (and subdirectories)
/path/to/static/linking/include/files (and subdirectories)
/path/to/static/linking/lib/files' (and subdirectories)
I would like to use xcscope to navigate/look up symbols in my code and the library that I am linking to.
The instructions for xcscope.el say that I should first run C-c s (Cscope->Create list and index) at /path/to/my/code, but I am then confused about how I to have the other paths indexed by cscope.
The documentation says I should go to the other directories and run cscope -b, but what I am supposed to do after that?
I looked at the cscope.files file that C-c s built. I think I am supposed to add my other paths to this file, but this file includes a list of source code files (not directories).
Do I have to manually edit cscope.files to add every single file that I want to index that is outside of my project's root directory?
The documentation is confusing.
I got one sol'n from http://cscope.sourceforge.net/large_projects.html. Still confusing.
cscope.files is aptly named. It is NOT directories. It is files, only files. Which is as daunting as it sounds. What if you have hundreds of files. Then you have to write hundreds of lines, one per file, into cscope.files. No joke.
Automate it with some scripting. E.g., on linux, use bash scripts and redirection (>,>>,|) operators to select and filter files from any and all directories into that cscope.files.
What about the directory where cscope.files resides? IF you don't include those files, it'll only find them when you open your project (in emacs, but probably applicable to any IDE) in that source directory. So, include them, too, for easy opening of your project from anywhere.
The option "recursive/-R" seems obvious to send to cscope-indexer. Nope, not with many root directories. Does nothing (probably could do something with scripts or elisp or who knows). Just feed those files, absolute path, into cscope.files. And you might have to make sure you have only one cscope.files per project. Don't split them up relative to each diretory. Or maybe you can, something to look into.
Remember, include the /path/to/each/file/ before the file if you want cscope.files to point to it from anywhere. cscope isn't "smart", it's dumb, it just takes directions for where to look and it won't know where to look for "filename", without knowing where it is. You're just asking it to call locate filename, which it can't do anyway, when you give it a lonely filename without a dir path outside of the directory that a particular cscope.files resides.
I hope there's a way to use xcscope inside emacs, just adding directories which it will catalog and index, as the xcscope docs and emacs menu suggest. But I didn't succeed in making it work that way.
Wouldn't a soft link (ln -s) work? Worked for me.
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.
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.