This question is a follow up to my earlier question How to automatically decompress a custom compressed file when opened in emacs?. Based on that, I was able tweak my init.el as follows
(defadvice jka-compr-info-compress-args (around eval-args activate)
"Evaluate program arguments"
(setq ad-return-value (mapcar 'eval (aref info 3))))
(defadvice jka-compr-info-uncompress-args (around eval-args activate)
"Evaluate program arguments"
(setq ad-return-value (mapcar 'eval (aref info 6))))
(add-to-list 'jka-compr-compression-info-list
["\\.tk\\'"
"TKing" "tksave" (filename)
"unTKing" "tkopen" (filename)
nil t ""])
"tk" is a custom compression tool that is being used internally in my custom. "tksave" and "tkopen" are the corresponding commands for compressing and decompressing respectively. "tkopen" is working fine by automatically uncompressing when I open a file but "tksave" saves the original file back rather the edited buffer visiting the file. How can I compress back the edited buffer to the file?
Remove your defadvice hacks and instead of your tksave and tkopen use programs which work as "unix filters" (i.e. take their input from stdin and send their output to stdout).
For tkopen you might get away with running tkopen /dev/stdin. And maybe for tksave you might also get away with tksave /dev/stdin. But both of those depend on exactly how those two commands work (e.g. if you do tkopen /foo/bar where is the uncompressed result sent? Same for tksave /foo/bar).
Related
Quite often I need to get a simple text copy of my currently opened files. The reasons are usually:
I want to send the list to a colleague
I want to document whatever I am working on (usually in an org document)
I want to act on one of my currently opened files, on the shell. I need to copy-paste the pathname for that.
The fact is that the usual buffer-menu or list-buffers provide a convenient menu to navigate the opened buffers, but are very inconvenient to copy-paste to the the terminal the names of the opened files, or to perform any of the actions mentioned above. For example: I can not double-click in a line to select the full path-name, and I can not use the kill/yank emacs sequence to copy around the path-name.
Summary: I would like a way to export to a text file (or to a new buffer) the list of opened files, without other data; no file size, mode, or any other emacs metadata.
Is there a command for that? An extra package I can install?
EDIT
Adding solution by Trey Jackson, modified to provide some feedback of what has been done:
(defun copy-open-files ()
"Add paths to all open files to kill ring"
(interactive)
(kill-new (mapconcat 'identity
(delq nil (mapcar 'buffer-file-name (buffer-list)))
"\n"))
(message "List of files copied to kill ring"))
This command will do the job for you:
(defun copy-open-files ()
"Add paths to all open files to kill ring"
(interactive)
(kill-new (mapconcat 'identity
(delq nil (mapcar 'buffer-file-name (buffer-list)))
"\n")))
You can change the mode of your *Buffer List* buffer. By default, it will be in mode Buffer Menu, but changing it to text-mode or fundamental-mode will remove all the special behavior allowing you to cut and paste from it just like a regular buffer. The metadata can easily be chopped off with delete-rectangle.
Alternatively, you can access the buffer list programmatically with elisp:
(dolist (buffer (buffer-list))
(when (buffer-file-name buffer)
(insert (buffer-file-name buffer) "\n")))
You certainly should be able to copy and yank from the buffer list.
e.g. copy everything with C-xhM-w and then yank into a new buffer for editing.
I need to process a file of certain types with external command line program accepting single argument (filename) and then use file modified by this program either open modified file or accept output of command line program as data source for file.
Any way to do this?
Where I used to work there were some binary files that I wanted to view in emacs. The way I did this was to add to jka-compr-compression-info-list like the following for editing applescripts:
(add-to-list 'jka-compr-compression-info-list
["\\.scpt\\'"
"Compiling" "osacompile-helper.sh" nil
"Decompiling" "osacompile-helper.sh" ("-d")
nil nil "Fasd"])
(jka-compr-update)
Here osacompile-helper.sh is just a little shell wrapper around osacompile and osadecompile that reads from stdin and writes to stdout (which is required). You also need to turn on auto-compression-mode, although I think that's the default. If you use the customize interface to change jka-compr-compression-info-list, instead of setting it directly, then you don't have to call jka-compr-update.
If you just want this to work when you open the file with C-x C-f, then you can probably just attach your behaviour to find-file, but deeper down I believe insert-file-contents is what eventually reads files in.
A cursory look doesn't seem to show any appropriate hook, so you could look at doing this with before advice.
(defadvice insert-file-contents
(before my-before-insert-file-contents-advice)
"Process files externally before reading them."
(let ((filename (expand-file-name (ad-get-arg 0))))
(message "About to read file %s" filename)
;; your code here.
;; ;; stupid unsafe example:
;; (let ((file (shell-quote-argument filename))
;; (tempfile (shell-quote-argument (make-temp-file "some-prefix-"))))
;; (shell-command (format "sort %s >%s" file tempfile))
;; (shell-command (format "mv %s %s" tempfile file)))
))
(ad-activate 'insert-file-contents)
You might like to elaborate on your requirements, in case you don't actually need to clobber the original file? (which I think is a horrendous idea, frankly; I certainly wouldn't use code like this!)
For example, you could read in the original file, process it within the buffer (maybe using shell-command-on-region with the replace flag), and set the buffer as unmodified. That way you are only likely to save the changes made by the shell command if you make other edits to the file, and the mere act of loading the file into an editor hasn't actually modified it.
In any case, I trust you'll implement sensible backup processes into your code, and will be plenty paranoid when testing!
You can call the external program with shell-command, with the output directed to a new buffer. A minimal working example is:
(defun my-find-and-process-file ()
(interactive)
(let* ((file (read-file-name "File name: "))
(buf (pop-to-buffer file)))
(shell-command (format "cat %s" file) buf)))
Replace cat with the name of your program. This will create a buffer and fill it with the output of your program. If a buffer with the name of your file already exists, it will over-write it. If that's a possibility, you will want to change the buffer name to something safe by adding a suffix or something. This code also doesn't trigger any of the find-file hooks, so you'll have to manually select the mode, or modify the code to do that for you.
Working with >1 Emacs (on >1 machine), and want to check all open buffers for changes (they are open remotely via tramp/ssh) when I resume working on a particular Emacs.
Different Emacs might not have the exact same files open, but there is probably crossover.
Not using Desktop mode or anything flash like that (yet).
Thanks!
If you are wanting buffers to revert in Emacs when the associated files are changed by another program, then you should look at
C-hf global-auto-revert-mode RET
If I understand correctly, you want to revert any buffers to their file's contents if the file has been modified outside emacs.
Here's a little snippet of lisp that will loop through the unmodified buffers and reloads the contents from disk:
(require 'cl)
(loop for buffer being the buffers
do (when
(and (not (buffer-modified-p buffer)) (buffer-file-name buffer))
(switch-to-buffer buffer)
(revert-buffer nil t)))
I am upgrading to emacs23. I find that my emacs.el loads much more slowly.
It's my own fault really... I have a lot of stuff in there.
So I am also trying to autoload everything possible that is currently "required" by my emacs.el.
I have a module that exposes 12 entry points - interactive functions I can call.
Is the correct approach to have 12 calls to autoload in order to insure that the module is loaded regardless of which function I call? Are there any problems with this approach? Will it present performance issues?
If not that approach, then what?
What you really want is to get the autoloads generated for you automatically, so that your .emacs file remains pristine. Most packages have the ;;;###autoload lines in them already, and if not, you can easily add them.
To manage this, you can put all the packages in a directory, say ~/emacs/lisp, and in there have a file named update-auto-loads.el which contains:
;; put this path into the load-path automatically
;;;###autoload
(progn
(setq load-path (cons (file-name-directory load-file-name) load-path)))
;;;###autoload
(defun update-autoloads-in-package-area (&optional file)
"Update autoloads for files in the diretory containing this file."
(interactive)
(let ((base (file-truename
(file-name-directory
(symbol-file 'update-autoloads-in-package-area 'defun)))))
(require 'autoload) ;ironic, i know
(let ((generated-autoload-file (concat base "loaddefs.el")))
(when (not (file-exists-p generated-autoload-file))
(with-current-buffer (find-file-noselect generated-autoload-file)
(insert ";;") ;; create the file with non-zero size to appease autoload
(save-buffer)))
(cd base)
(if file
(update-file-autoloads file)
(update-autoloads-from-directories base)))))
;;;###autoload
(defun update-autoloads-for-file-in-package-area (file)
(interactive "f")
(update-autoloads-in-package-area file))
If you add 'update-autoloads-in-package-area to your kill-emacs-hook, then the loaddefs.el will automatically be updated every time you exit Emacs.
And, to tie it all together, add this to your .emacs:
(load-file "~/emacs/lisp/loaddefs.el")
Now, when you download a new package, just save it in the ~/emacs/lisp directory, update the loaddefs via M-x update-autoloads-in-package-area (or exit emacs), and it'll be available the next time you run Emacs. No more changes to your .emacs to load things.
See this question for other alternatives to speeding up Emacs startup: How can I make Emacs start-up faster?
Well, who cares how slowly it starts?
Fire it up via emacs --daemon & and then connect using either one of
emacsclient -c /some/file.ext, or
emacsclient -nw
I created aliases for both these as emx and emt, respectively. Continuing once editing session is so much saner...
Ideally you shouldn't have any load or require in your .emacs file.
You should be using autoload instead...
e.g.
(autoload 'slime-selector "slime" t)
You will need to use eval-after-load to do any library specific config, but the upshot is that you won't need to wait for all this to load up front, or cause errors on versions of Emacs that don't have the same functionality. (e.g. Terminal based, or a different platform etc.)
While this may not affect you right now, chances are, in future you will want to use the same config on all machines / environments where you use Emacs, so it's a very good thing to have your config ready to fly.
Also use (start-server) and open external files into Emacs using emacsclient - So you avoid restarting Emacs.
I would like emacs to mark files that are generated as read-only when they're opened. The part of the puzzle that I'm missing is how to check if a file "exists". I currently have the following:
;;
;; get file extension
;;
(defun get-ext (file-name)
(car (cdr (split-string file-name "\\."))))
;;
;; get the base name of the file
;;
(defun base-name (file-name)
(car (split-string file-name "\\.")))
;;
;; if an 'lzz' file exists for this header, mark it as read only
;;
(defun mark-read-only ()
(if (string= (get-ext (cur-file)) "h")
(if ( ??file-exists??? (concat (base-name (cur-file)) ".lzz") )
(toggle-read-only))))
What can I use for "???file-exists???"?
Once I find this, I'll add "mark-read-only" to the appropriate hook (which I think is the find-file-hook).
BACKGROUND
We use lzz as a code generator to simplify our C/C++ development process. Briefly, lzz takes a single input file (which looks very like C/C++) and generates header and source files as appropriate.
By default, lzz includes #line directives so that the debugger points to the original source and not the generated source, however, to reduce compilation dependencies we normally disable these directives in header files. The result is that when debugging templates or inline functions, the debugger normally points to the generated header file and not the original source file.
This is not a big deal, however, recently I've found that when debugging I'll make a quick modification to the displayed file and then I'll rebuild. Of course this normally means that the change I made disappears because the file I edited is generated and so the changes are "blown away" during the library rebuild.
SOLUTION
Thanks to everyone for their help and comments. A special thanks to cobbal for pointing out the correct function to use.
Here's the resulting code (with updates based on the other comments here too):
(defun cur-file ()
"Return the filename (without directory) of the current buffer"
(file-name-nondirectory (buffer-file-name (current-buffer)))
)
(defun mark-generated-as-read-only ()
"Mark generated source files as read only.
Mark generated files (lzz or gz) read only to avoid accidental updates."
(if
(or (string= (file-name-extension (cur-file)) "h")
(string= (file-name-extension (cur-file)) "cpp"))
(cond
(
(file-exists-p (concat (file-name-sans-extension (cur-file)) ".lzz"))
(toggle-read-only))
(
(file-exists-p (concat (file-name-sans-extension (cur-file)) ".gz") )
(toggle-read-only))
)
)
)
try file-exists-p
"Return t if file filename exists (whether or not you can read it.)".
Note that it's not spesific to files and works for directories too.
Depending on what you need, you might want file-readable-p instead of file-exists-p.
Apropos will only get you so far. Icicles provides apropos completion and progressive completion which let you find help easily for command, function, variable, etc. names that match subparts in an arbitrary order (is it file-exists-p or exists-file-p?).
Use f.el, modern library for file and directory manipulation. You can use f-exists?, f-file?, f-directory? and many other predicates. The library is better than standard functions, because it's every file related function you'll ever need under one namespace.