Most of your assumptions are close. I'll mention a few later. But, first the main question.
The form setq-local is merely a convenience, it is the same as doing make-local-variable followed by setq. If you had done a C-h f setq-local to see the documentation and clicked through to the source you might have seen this. That's how I verified my first ...
Set the safe-local-variable property to a function that validates the value. For example, fill-column has a safe-local-variable property set to integerp. Use (lambda (x) t) as the validation function if any value is valid.
(defvar my-variable-with-any-safe-value …)
(put 'my-variable-with-any-safe-value 'safe-local-variable
(lambda (x) t))
As noted by @phils in the comment below, the Emacs manual suggests not modifying the face-remapping-alist directly due to possible unintended side effects: . . .to avoid trampling on remappings applied elsewhere. Thus, (setq-local face-remapping-alist '((stripe-highlight (:background "white" :foreground "black")))) is not considered to be the preferred ...
The comment from @Malabarba explains your problem.
kill-local-variable does get rid of the local variable binding. But since in your case the variable is automatically local in any buffer, when you reassign it a value, that value is local.
AFAIK, there is no way to counter make-variable-buffer-local, except to use unintern on the symbol. (makunbound does ...
Here's how you can tell org-mode to set buffer-file-name to an appropriate value for code buffers:
(defadvice org-edit-src-code (around set-buffer-file-name activate compile)
(let ((file-name (buffer-file-name))) ;; (1)
ad-do-it ;; (2)
(setq buffer-file-name file-name))) ;; (3)
C-c ' is bound to org-edit-...
First off, since you didn't mention it: Using the same version of Emacs (24.4.1), the behavior you describe can be reproduced in emacs -Q.
Secondly, what you are doing should work (AFAICT). It seems that turning on whitespace-mode globally (or even in a mode hook) before visiting a file with a custom whitespace-line-column is what's causing the problem. You ...
(add-hook 'before-save-hook #'clang-format-buffer nil t)
This is the right way to add a function locally to a hook.
This will set before-save-hook as a buffer local variable ignoring everything that I set globally.
No, it won't. The global value will still exist, and run-hooks will run both values.
before-save-hook is no exception here, try it out and ...
This is very similar to the question Is there a way to disable the “buffer is read-only” warning?, so a very similar answer seems appropriate.
You can disable these messages by setting command-error-function to a function that ignores signals buffer-read-only, beginning-of-buffer, and end-of-buffer.
(defun my-command-error-function (data context caller)
Both the buffer-local and the global variable are initially pointing to the same cons cell / list. If setenv pushes a new value to the front of the list, that would only be reflected in the local list value (the global value would effectively point to the cdr of the local value) in which case your code should work as desired; however if setenv is modifying ...
is there a way to do this without changing the current buffer
No, but buffer-local-value is a Generalized Variable, so you can use setf to take care of the buffer switching for you:
(setf (buffer-local-value 'some-var B) 'some-val)
This macroexpands to essentially the same code as what your wrote above:
(let* ((#1=#:v B))
I, as a package author, bind case-fold-search to nil in the outer let, and I want to use the default value (it might or might not be set by the user) in the with-temp-buffer,
In this case I would recommend
(let ((case-fold-search (progn (make-local-variable 'case-fold-search)
This is standard functionality built into add-hook:
add-hook is a compiled Lisp function in ‘subr.el’.
(add-hook HOOK FUNCTION &optional APPEND LOCAL)
Add to the value of HOOK the function FUNCTION.
FUNCTION is not added if already present.
FUNCTION is added (if necessary) at the beginning of the hook list
unless the optional argument ...
permanent-local is fundamentally a way to distinguish whether the variable's buffer-local value is really specific to this buffer or is specific to the mode currently in use in this buffer.
Sadly, in practice, for many buffer-local variables which are not specific to a particular package, whether the setting belongs to the buffer or to the mode will depend ...
If you want to set a buffer-local value for a variable, use setq-local.
Depending on what you are actually trying to accomplish, you may also want to look at the help for make-local-variable and make-variable-buffer-local. These functions do not actually set a value, but arrange for a variable to have a buffer-local value when set.
The immediate difference is that setq-mode-local will also affect already existing buffers, whereas adding a setq-local to the mode hook will only affect future buffers.
Of course, there are other differences due to the underlying mechanisms used, but I think to a first approximation, this is the only real difference.
Not as such. Even 'global' minor modes are generally just buffer-local minor modes which are enabled or disabled for multiple buffers en masse.
However there's nothing to stop you writing a global mode (or hook function, or whatever approach makes the most sense) which is ostensibly active everywhere, but which checks the window of the current buffer, and ...
I am certain that the answer is no, and that variables are the only kind of buffer-local bindings provided by elisp. (I'm sure one of the elisp language maintainers will correct me if I'm wrong about this.)
There are a handful of other kinds of "local" values (such as frame parameters, and terminal-local variables), and other things may also be associated ...
What you're doing is correct.
is there a way to do this without changing the current buffer, i.e. can I explicitly specify the buffer whose value I want to change?
While there is nothing built in, you can trivially write a macro which takes all three arguments, and then does exactly what you were doing.
Save your data as a window-parameter. It will force you to use :eval inside your mode-line, but that's not something to be afraid of.
If you want to discuss changes to the "core" Emacs features (like adding window-local variables), then the emacs-devel mailing-list is the place to do it. In this particular case I don't think there's much chance of success ...
You can add not only action but any other attributes to a text-button, that can be referred later with button-get function. So saving the (reference to the) current buffer, together with action, seems a good idea here.
'action (lambda (b)
(with-current-buffer (button-get b '...
kill-buffer-hook is not automatically buffer-local. That it is, it does not automatically become buffer-local whenever its value is set.
AFAICT, auto-revert-mode does not make kill-buffer-hook be buffer-local.
Something else in your setup no doubt does make it buffer-local in some buffer.
kill-buffer-hook, although not buffer-local to start with, has the ...
Not exactly sure what the question is, but this might help. It's hard to add to what is said in the doc section you cite - I think that section describes the situation well.
A buffer is in a (major) mode. When the major mode is turned on (becomes active), one of the things that happens (by the major-mode function's code) is that all (buffer) local ...
Sounds like my-package-insert turns on a major mode. Doing that calls kill-all-local-variables.
You can give the variable a non-nil permanent-local property to protect it. But we would need more info to be able to suggest whether that is a good idea in your context.
If you don't need the variable to be bound before my-package-insert then consider binding ...
You want to look at the functions that use line-move-visual / line-move-1 / line-move -- within the library simple.el. The error message occurs because the optional argument of noerror is not being used to suppress the error message.
However, some functions depend upon that signal error to halt an ongoing function -- e.g., the third-party optional library ...
When you see Automatically becomes buffer-local when set you can rely on it meaning just what it says: whenever that variable is set (e.g., using setq), it becomes buffer-local if it was not already buffer-local. So yes, setq sets the buffer-local value, and if you want to set the global, default value then you need to use setq-default.
If you want to set a buffer-local value for a given mode, do so after the mode has been established. You do that by putting the value-assignment on the mode hook.
For example, if you want to set local variable foo to 42 in lisp-mode then do something like this:
(add-hook 'lisp-mode (lambda () (setq-local fill-paragraph-function 'my-fill-para)))
Or better ...
The doc you show isn't for advice-add but for add-function (which is used internally by advice-add but offers other functionality, such as working on variables (which can be buffer-local) rather than functions (which can't be buffer-local)).
Without knowing more details, I can't give an exact solution, but usually to do what you want you'll use something ...
That's actually a bit tricky on account of how shell is written, so the following is quite implementation-specific and could break if things change upstream; however, give this a whirl:
(defadvice make-comint-in-buffer (before my-shell-dir-locals)
(when (string= (ad-get-arg 0) "shell")
Error is caused by this quote:
# -*- browse-url-browser-function: 'browse-url-chromium -*-
It shouldn't be there.
Open video path in MPV on *nix OS's
Add this line to the init file(.emacs), or evaluate in Scratch buffer
(org-add-link-type "mpv" (lambda (path) (browse-url-xdg-open path)))
browse-url-xdg-open uses xdg-...
(defvar my-hist nil)
(defun my-function (hist)
(read-from-minibuffer "> " nil nil nil hist))
(defun my-command ()
(add-to-history 'my-hist (my-function 'my-hist)))
Don't quote hist when you pass it to read-from-minibuffer. You want to pass its value, e.g. the symbol my-hist, and not ...