I read the manual at http://www.gnu.org/software/emacs/manual/html_node/elisp/Saving-Buffers.html#Saving-Buffers, but still not quite understand what is the difference between the two. It seems to me they both work as a hook to run whatever function you set before saving the buffer to the visited file. could anyone explain with examples? Thanks.
write-file-functions can be used to simply do arbitrary things before saving the file, but its stated purpose is to allow some non-default function to actually do the work of saving the file (or perhaps to manipulate the content for the purposes more directly related to the saving mechanism itself).
If modifying the mechanism for saving a file is not what you wish to do, I strongly suspect you should be using before-save-hook.
See also C-hig (elisp) Saving Buffers RET
write-*-functions provide a strict superset of what before-save-hook can do. More specifically, write-*-functions can replace the normal saving mechanism with another one. This means that a function added to write-*-functions might end up unused because some earlier function has already saved the buffer.
Well I would say that before-save-hook is here to modify the content. While write-*-functions are in charge of coding systems (compress the file content for instance or following any other file format) and the backup files.
Moreover write-*-functions may be buffer local while it does not seem to be the case for before-save-hook. But then I am not sure to know what it implies.
Related
I've been using Org-mode a few months, and as I customize Emacs, I'm having a lot of difficulty finding documentation on how to specifically customize various variables.
Example: I've successfully set up archiving, but want to customize the org-archive-save-context-info variable to reduce the info that's archived along with the task. I do not want to do this per-file, but in my config file. Despite my best efforts, I don't see documentation on syntax and parameters for customizing this.
I do see some documentation when I customize the variable in the Emacs UI--but I'm looking for documentation so I can see syntax and parameters for customizing this myself via a config file. I can learn it backwards this way (via 'easy customization'): customize a variable, see what Emacs wrote to the config, try tweaking that, etc.
[EDIT] I'm talking about info below the task that appears after archiving, like this:
:PROPERTIES:
:ARCHIVE_TIME: 2018-09-10 Mon 11:24
:ARCHIVE_FILE: ~/Dropbox/logs/capture.org
:ARCHIVE_OLPATH: Tasks
:ARCHIVE_CATEGORY: capture
:ARCHIVE_TODO: DONE
:END:
Is this intentional? Do I just need to 'know ELisp' first? Is the intention that you use the Emacs point-and-click UI to customize things like this? Happy to RTFM if I could find the FM.
Is the intention that you use the Emacs point-and-click UI to customize things like this?
It's certainly intended that you would use the customize interface if you don't know elisp (and you might well choose to use it even if you do).
Do I just need to 'know ELisp' first?
Yes, you'll need at least some familiarity with elisp in order to understand the documentation and be able to write your own config changes. This is because elisp is the configuration language for Emacs, and so the documentation is written in that context. (It wouldn't make sense for basic lisp concepts to be explained and repeated in every piece of documentation which used them.)
That said, many people get by just copying and pasting from config examples -- and you're likely to pick up the basics this way, even if you don't fully understand them. If you're serious about Emacs, though, spending some time to learn about elisp will be hugely beneficial to you in future.
I can learn it backwards this way (via 'easy customization'): customize a variable, see what Emacs wrote to the config, try tweaking that, etc.
That's an entirely reasonable thing to do.
FWIW C-hv org-archive-save-context-info is actually very clear if you have the background understanding.
This variable can be a list of any of the following symbols:
time The time of archiving.
file The file where the entry originates.
ltags The local tags, in the headline of the subtree.
itags The tags the subtree inherits from further up the hierarchy.
todo The pre-archive TODO state.
category The category, taken from file name or #+CATEGORY lines.
olpath The outline path to the item. These are all headlines above
the current item, separated by /, like a file path.
That tells you that you might use the following in your config file:
(setq org-archive-save-context-info '(time file todo))
Happy to RTFM if I could find the FM.
You can start learning about elisp in the "Emacs Lisp Intro" manual, which you should find near the top of the Info directory, or jump to directly with C-hig (eintr) RET. Type h from there if you need to learn how to use the Info reader.
I have helm-find-files bound to C-x C-f since it provides a much more convenient way to open files. Unfortunately for me, if point is currently inside something that looks like a filename then that alters helm-find-files's behaviour, often changing its current directory. (See https://github.com/emacs-helm/helm/issues/1178 )
Is there a straightforward way for me to nobble thing-at-point inside helm-find-files-initial-input so that it never believes point is inside a filename? I thought that defadvice would help but I'm having trouble working out how.
Or perhaps there's a better way to make helm-find-files behave consistently no matter where point is without modifying its implementation directly?
You can set helm-find-file-ignore-thing-at-point to t.
Documentation:
Use only ‘default-directory’ as default input in ‘helm-find-files’.
I.e text under cursor in ‘current-buffer’ is ignored.
Note that when non-nil you will be unable to complete filename at point
in ‘current-buffer’.
No matter how many times I reload my .emacs file,
M-x load-file RET ~/.emacs RET
I want the results to be the same as the first time. I want to make my .emacs file be idempotent.
Motivation
I know I can surgically evaluate a region (C-c C-r), a defun (C-M-x), or the last sexp (C-x C-e). I often take such a more refined approach when making small changes. However, when re-working a .emacs file, I sometimes want to check results of the change conclusively by reloading the entire .emacs file. Restarting emacs each time gets old quick, especially when doing major .emacs housekeeping.
Specific Steps
What specific steps must I take to update my .emacs file to replace non-idempotent operations with idempotent ones?
For example,
Search for "-hook" and replace direct additions to hooks with calls to add-hook, which
will not re-add a function to the hook if already there.
Replace toggling of any flags with direct setting or clearing. Beware of ?? in particular.
...
A comprehensive check-and-correct list would be ideal, but any key individual checks that occur to you would be helpful as well.
I don't know as it's possible to ensure this completely, as most .emacs files depend on libraries which may not have idempotent initialization routines. However, there are a few useful tricks to reduce problems:
Use named functions for add-hook, and keybindings instead of anonymous functions. For add-hook in particular, this allows it to swap out the existing reference.
Careful use of defvar, by default the body is only evaluated if the variable is undefined. C-M-x on a defvar will re-eval the body, but eval-buffer will not if the variable is already initialized.
Careful use of (quote function) instead of function to reference a named function instead of the value of the function. See Anonymous Functions for more advanced discussion about this.
Remember that require will only load the corresponding library the first time it is executed, it will not re-eval on repeated calls as load does. Autoload also uses require to load the corresponding library.
Prefer add-to-list instead of cons to only add an element if it doesn't exist.
For older mode activation, make sure to use (mode-name-mode t) to activate instead of the toggle function. Likewise for turn-on- minor mode functions instead of the mode toggle.
Guard blocks that do have side effects if executed repeatedly. In particular for server mode, (unless (server-running-p) (server-start)), and similar guards for installing packages.
Being careful about side effects in eval-after-load or custom mode hooks. Remember the default mode hooks run when a mode is first enabled, and on each subsequent buffer, but will not rerun in existing buffers when the hook function is modified. eval-after-load is less likely to trip things up, it's still important to remember when it's evaluated.
Related to #2, makunbound may be useful if a chain of vars that depend on each other need to be re-evaluated, as it will force the defvar to always execute on evaluation of the file.
Running eval-buffer on an init file should be as idempotent as possible, but it's important to remember that emacs lisp is fond of side effects and state. While it's possible to ameliorate this to some extent, re-evaling init will never return emacs to the state it was when it first started.
Limit yourself to things you know are idempotent:
defun.
setq to a constant.
add-to-list with a constant.
add-hook, but preferably adding a symbol rather than a lambda expression.
enabling/disabling a minor mode.
wrapping some of the above in conditions.
Of course idempotent doesn't actually mean that the result is the same as re-starting (e.g. removing a setq and then re-evaluating your .emacs won't remove the effect of the previous setq), but the above is pretty much the principles I try to follow in my own ~/.emacs.
In addition to what others have said, load (e.g. require) libraries, including 3rd-party libraries, whose loading is idempotent.
Yes, to find that out for a given library you might need to either read the code or experiment. But nowadays libraries are supposed to be idempotent (or close to it), and many are.
I was reading this question and the answers are a convoluted mess (timer function REALLY?)
In any case, I don't care about recreating these buffers, as that is trivial. But these buffers contain information which should never be deleted, and because they don't have associated filenames, they are usually killed without confirmation.
I do have a solution in mind, but I want to see if someone has a more "canonical" one.
jtahlborn provided the most canonical solution, except the "keep-buffers" package is showing its age has some issues:
You had to specify whether all protected buffers are to be buried and erased (erased buffers can be recovered with `undo') when killed, or just buried when killed.
member is reimplemented as find-in-list less efficiently.
Helper functions that didn't really help.
I made the the protected-list an alist that associates regexp to erase-action, and deleted the useless (IMO) code. By default, "scratch" is erased when killed, "Messages" is never erased or killed.
See github
You can try adding a function to the kill-buffer-query-functions variable that checks the current buffer, if it is scratch or Messages then return nil. I've never tried this before but it should prevent them from getting killed.
Edit: Here's an example of using kill-buffer-query-functions that allows you to protect specific buffers: http://www.emacswiki.org/emacs/protbuf-by-name.el
i use the keep-buffers utility.
In addition to what has been said by others --
*scratch* is in no way a "vital" buffer. And by default nothing and no one automatically writes anything to *scratch* or modifies anything there.
(FWIW, I tend to use an ordinary Emacs-Lisp mode file buffer instead of *scratch*. One reason is that I do typically want to save it at some point. (Another reason: I prefer that C-j do what it does in Emacs-Lisp mode. Yes, I could change just that key binding, but instead I keep *scratch* for some kinds of interaction, but typically not for a coding sandbox.)
*Messages* is a different story.
But how are you accidentally deleting *Messages*? In decades of using Emacs I don't think I've ever accidentally killed *Messages*. What's the scenario to produce the problem you are looking for a solution to?
I can use process-name to get the name of the process, but can I change the name after starting it? I looked in the manual, and even in the source and haven't found anything that seems like it would do this.
There's only one line in Emacs' process.c source file where p->name is set for a process p, and that is in the function make_process. All other functions just read that value, they never (re-)set it. So it seems the answer to your question is "no".
You could, of course, try to implement your own function that changes the name of a process. See here
for more information.