I would like to customize the following variables that were newly introduced in Emacs 28.1.
isearch-wrap-pause (defined with defcustom in isearch.el, default value t)
isearch-repeat-on-direction-change (defined with defcustom in isearch.el, default value nil)
I have the following in my init file.
(setq isearch-wrap-pause nil
isearch-repeat-on-direction-change t)
I see the desired effect with this setting. But, I don't see the expected effect when setting isearch-wrap-pause to no or no-ding (other values as defined in isearch.el).
I've tried with
(setq isearch-wrap-pause 'no
isearch-repeat-on-direction-change t)
and
(setq isearch-wrap-pause "no"
isearch-repeat-on-direction-change t)
and
(setq isearch-wrap-pause no
isearch-repeat-on-direction-change t)
without success.
How do I set isearch-wrap-pause to no or no-ding?
Edit [As on 2022-07-22]:
The expected behaviour I was looking for was to wrap around automatically when searching incrementally. I raised a bug with Emacs developers and they informed that this is not the intended behaviour, and automatic wrapping happens only for repeated search and not incremental search.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56535
The expected behaviour I was looking for was to wrap around automatically when searching incrementally. I raised a bug with Emacs developers and they informed that this is not the intended behaviour, and automatic wrapping happens only for repeated search and not incremental search
It looks like there's been developments in the thread that was linked in the question (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56535). It's now possible to (setq isearch-wrap-pause 'no-ding) or (setq isearch-wrap-pause 'no) to automatically wrap the search even if you're doing incremental searching (I'm using emacs 29, not sure if it's also on emacs 28)
Related
Is there a proper predicate for determining whether the window has focus in the mode line? I'm trying to do some things in my mode line that require more flexibility than just using mode-line-inactive.
I've been doing:
(defun window-has-focus-p ()
"When called in eval sexp in mode or header line template,
returns true if this is the active window."
(eq
(frame-selected-window)
(get-buffer-window)))
And it worked very well on two of my computers for months (Windows 7 and Debian). However, I tried using it on another Debian box yesterday and it reported t in every mode line for every window... totally broken.
I haven't been able to find a standard predicate call for this purpose, and I can't figure out why this hacked-up one seems to work on some devices and not others. Additionally, I did evaluate (force-mode-line-update t) with M-: and that did not help.
Emacs version is 24.3
While the mode-line-format is evaluated for a given window, this window is temporarily made the selected-window. In Emacs<=24.3 this was made only halfway: selected-window was changed, but not frame-selected-window. This meant that temporarily (frame-selected-window) was not equal to (selected-window) and breaking this (normally) invariant was a source of various corner case bugs. So we fixed it in 24.4, which means that your code broke.
To make it work in 24.4, you need to save the "selected-window" as seen by the user before the mode-line-format is processed.
You can do that with
(defvar my-real-selected-window nil)
(add-function :before pre-redisplay-function
(lambda (_wins) (setq my-real-selected-window (selected-window))))
So you can then use my-real-selected-window in your mode-line-format to know which window is the one that should be highlighted specially.
I have been using this in my configuration
;;; active modeline detection hack
(add-hook 'post-command-hook
(lambda ()
(when (not (minibuffer-selected-window))
(setq powerline-selected-window (selected-window)))))
Maybe the post-command-hook is not the most elegant solution, but is working correctly for me.
I'm committing to a project where standard indentations and tabs are 3-chars wide, and it's using a mix of HTML, PHP, and JavaScript. Since I use Emacs for everything, and only want the 3-char indentation for this project, I set up a ".dir-locals.el" file at the root of the project to apply to all files/all modes under it:
; Match projets's default indent of 3 spaces per level- and don't add tabs
(
(nil .
(
(tab-width . 3)
(c-basic-offset . 3)
(indent-tabs-mode . nil)
))
)
Which works fine when I first open a file. The problem happens when switching major modes- for example to work on a chunk of literal HTML inside of a PHP file. Then I lose all the dir-local variables.
I've also tried explicitly stating all of the modes I use in ".dir-locals.el", and adding to my .emacs file "dir-locals-set-class-variables / dir-locals-set-directory-class". I'm glad to say they all behave consistently, initially setting the dir-local variables, and then losing them as I switch the major mode.
I'm using GNU Emacs 24.3.1.
What's an elegant way of reloading dir-local variables upon switching a buffer's major-mode?
-- edit -- Thanks for the excellent answers and commentary both Aaron and phils! After posting here, I thought it "smelled" like a bug, so entered a report to GNU- will send them a reference to these discussions.
As per comments to Aaron Miller's answer, here is an overview of what happens when a mode function is called (with an explanation of derived modes); how calling a mode manually differs from Emacs calling it automatically; and where after-change-major-mode-hook and hack-local-variables fit into this, in the context of the following suggested code:
(add-hook 'after-change-major-mode-hook 'hack-local-variables)
After visiting a file, Emacs calls normal-mode which "establishes the proper major mode and buffer-local variable bindings" for the buffer. It does this by first calling set-auto-mode, and immediately afterwards calling hack-local-variables, which determines all the directory-local and file-local variables for the buffer, and sets their values accordingly.
For details of how set-auto-mode chooses the mode to call, see C-hig (elisp) Auto Major Mode RET. It actually involves some early local-variable interaction (it needs to check for a mode variable, so there's a specific look-up for that which happens before the mode is set), but the 'proper' local variable processing happens afterwards.
When the selected mode function is actually called, there's a clever sequence of events which is worth detailing. This requires us to understand a little about "derived modes" and "delayed mode hooks"...
Derived modes, and mode hooks
The majority of major modes are defined with the macro define-derived-mode. (Of course there's nothing stopping you from simply writing (defun foo-mode ...) and doing whatever you want; but if you want to ensure that your major mode plays nicely with the rest of Emacs, you'll use the standard macros.)
When you define a derived mode, you must specify the parent mode which it derives from. If the mode has no logical parent, you still use this macro to define it (in order to get all the standard benefits), and you simply specify nil for the parent. Alternatively you could specify fundamental-mode as the parent, as the effect is much the same as for nil, as we shall see momentarily.
define-derived-mode then defines the mode function for you using a standard template, and the very first thing that happens when the mode function is called is:
(delay-mode-hooks
(PARENT-MODE)
,#body
...)
or if no parent is set:
(delay-mode-hooks
(kill-all-local-variables)
,#body
...)
As fundamental-mode itself calls (kill-all-local-variables) and then immediately returns when called in this situation, the effect of specifying it as the parent is equivalent to if the parent were nil.
Note that kill-all-local-variables runs change-major-mode-hook before doing anything else, so that will be the first hook which is run during this whole sequence (and it happens while the previous major mode is still active, before any of the code for the new mode has been evaluated).
So that's the first thing that happens. The very last thing that the mode function does is to call (run-mode-hooks MODE-HOOK) for its own MODE-HOOK variable (this variable name is literally the mode function's symbol name with a -hook suffix).
So if we consider a mode named child-mode which is derived from parent-mode which is derived from grandparent-mode, the whole chain of events when we call (child-mode) looks something like this:
(delay-mode-hooks
(delay-mode-hooks
(delay-mode-hooks
(kill-all-local-variables) ;; runs change-major-mode-hook
,#grandparent-body)
(run-mode-hooks 'grandparent-mode-hook)
,#parent-body)
(run-mode-hooks 'parent-mode-hook)
,#child-body)
(run-mode-hooks 'child-mode-hook)
What does delay-mode-hooks do? It simply binds the variable delay-mode-hooks, which is checked by run-mode-hooks. When this variable is non-nil, run-mode-hooks just pushes its argument onto a list of hooks to be run at some future time, and returns immediately.
Only when delay-mode-hooks is nil will run-mode-hooks actually run the hooks. In the above example, this is not until (run-mode-hooks 'child-mode-hook) is called.
For the general case of (run-mode-hooks HOOKS), the following hooks run in sequence:
change-major-mode-after-body-hook
delayed-mode-hooks (in the sequence in which they would otherwise have run)
HOOKS (being the argument to run-mode-hooks)
after-change-major-mode-hook
So when we call (child-mode), the full sequence is:
(run-hooks 'change-major-mode-hook) ;; actually the first thing done by
(kill-all-local-variables) ;; <-- this function
,#grandparent-body
,#parent-body
,#child-body
(run-hooks 'change-major-mode-after-body-hook)
(run-hooks 'grandparent-mode-hook)
(run-hooks 'parent-mode-hook)
(run-hooks 'child-mode-hook)
(run-hooks 'after-change-major-mode-hook)
Back to local variables...
Which brings us back to after-change-major-mode-hook and using it to call hack-local-variables:
(add-hook 'after-change-major-mode-hook 'hack-local-variables)
We can now see clearly that if we do this, there are two possible sequences of note:
We manually change to foo-mode:
(foo-mode)
=> (kill-all-local-variables)
=> [...]
=> (run-hooks 'after-change-major-mode-hook)
=> (hack-local-variables)
We visit a file for which foo-mode is the automatic choice:
(normal-mode)
=> (set-auto-mode)
=> (foo-mode)
=> (kill-all-local-variables)
=> [...]
=> (run-hooks 'after-change-major-mode-hook)
=> (hack-local-variables)
=> (hack-local-variables)
Is it a problem that hack-local-variables runs twice? Maybe, maybe not. At minimum it's slightly inefficient, but that's probably not a significant concern for most people. For me, the main thing is that I wouldn't want to rely upon this arrangement always being fine in all situations, as it's certainly not the expected behaviour.
(Personally I do actually cause this to happen in certain specific cases, and it works just fine; but of course those cases are easily tested -- whereas doing this as standard means that all cases are affected, and testing is impractical.)
So I would propose a small tweak to the technique, so that our additional call to the function does not happen if normal-mode is executing:
(defvar my-hack-local-variables-after-major-mode-change t
"Whether to process local variables after a major mode change.
Disabled by advice if the mode change is triggered by `normal-mode',
as local variables are processed automatically in that instance.")
(defadvice normal-mode (around my-do-not-hack-local-variables-twice)
"Prevents `after-change-major-mode-hook' from processing local variables.
See `my-after-change-major-mode-hack-local-variables'."
(let ((my-hack-local-variables-after-major-mode-change nil))
ad-do-it))
(ad-activate 'normal-mode)
(add-hook 'after-change-major-mode-hook
'my-after-change-major-mode-hack-local-variables)
(defun my-after-change-major-mode-hack-local-variables ()
"Callback function for `after-change-major-mode-hook'."
(when my-hack-local-variables-after-major-mode-change
(hack-local-variables)))
Disadvantages to this?
The major one is that you can no longer change the mode of a buffer which sets its major mode using a local variable. Or rather, it will be changed back immediately as a result of the local variable processing.
That's not impossible to overcome, but I'm going to call it out of scope for the moment :)
Be warned that I have not tried this, so it may produce undesired results ranging from your dir-local variables not being applied, to Emacs attempting to strangle your cat; by any sensible definition of how Emacs should behave, this is almost certainly cheating. On the other hand, it's all in the standard library, so it can't be that much of a sin. (I hope.)
Evaluate the following:
(add-hook 'after-change-major-mode-hook
'hack-dir-local-variables-non-file-buffer)
From then on, when you change major modes, dir-local variables should (I think) be reapplied immediately after the change.
If it doesn't work or you don't like it, you can undo it without restarting Emacs by replacing 'add-hook' with 'remove-hook' and evaluating the form again.
My take on this:
(add-hook 'after-change-major-mode-hook #'hack-local-variables)
and either
(defun my-normal-mode-advice
(function &rest ...)
(let ((after-change-major-mode-hook
(remq #'hack-local-variables after-change-major-mode-hook)))
(apply function ...)))
if you can live with the annoying
Making after-change-major-mode-hook buffer-local while locally let-bound!
message or
(defun my-normal-mode-advice
(function &rest ...)
(remove-hook 'after-change-major-mode-hook #'hack-local-variables)
(unwind-protect
(apply function ...)
(add-hook 'after-change-major-mode-hook #'hack-local-variables)))
otherwise and finally
(advice-add #'normal-mode :around #'my-normal-mode-advice)
I'm facing a very bizarre behaviour. No matter how I set ac-auto-start, be it through customization, by evaluating (setq ac-auto-start 2), (setq-default ac-auto-start 2) or (setq-local ac-auto-start 2) immediately after I do it, the variable is set to nil.
I've looked through the source of auto-complete mode and the ac-slime in my case, but none of these does nothing to this variable. I am at a loss as to how to deal with this.
The effective consequences of this malfunction is that completion combobox doesn't appear on its own, unless I force it to by doing M-x auto-complete. This behaviour is consistent in all modes where auto-complete minor mode is enabled.
EDIT
This seems to be an issue with latest Emacs. Now it fails to modify variables values, no matter what variable it is. So, say, after running it with -Q I've now discovered that I can't evaluate the code that uses (setq ...) forms as it has no effect. :/ So, please, hold on, I'll try to investigate this...
This was due to the typo, but the original problem is still there.
Emacs version is 24.3.50.1 pulled from trunk about a week ago.
auto-complete is version 1.4 installed from MELPA.
I'm setting the variable by moving the point to the REPL buffer, then M-:. I check its value in the same way.
EDIT2
OK, I finally found the reason: I had enzyme package installed, and it had an earlier version of auto-complete inside of it, for some reason parts of the auto-complete code were loaded from there and other parts from the one installed from MELPA. After disabling enzyme it all works well now.
EDIT3
This still happens after I run (auto-complete-mode 1) in the REPL buffer. The variable will become impossible to set. I've searched through various autocomplete timers that may be setting something, but no luck so far.
There is indeed something strange going on with the setting of auto-complete-mode.
(I'm using the ELPA version in a GNU Emacs 24.3.1)
This is set up by customize-group RET auto-complete :
'(ac-auto-show-menu t)
'(ac-auto-start t)
At this point if you M-x auto-complete-mode you get a [no match] right in the minibuffer. Only after you try to M-x auto-complete, yelding a "auto-complete-mode is not enabled" weird error, will you be able to M-x auto-complete-mode (but without command completion... Hm) and then be in the mode.
If you put this in your init file (.emacs)
(require 'auto-complete)
(auto-complete-mode t)
It will be effective only if you re-eval it after startup (?!?).
The same with something like
(if (auto-complete)
(auto-complete-mode t))
The only way that I found to get auto-complete-mode to load at startup is to :
(eval-and-compile
(require 'auto-complete nil 'noerror))
(The above customize options are now effective)
Generally, how can I customize the value of a buffer-local variable in Emacs? For example, the variable w3m-lnum-mode is buffer-local, if I set (setq w3m-lnum-mode t) in .emacs, its value in a w3m mode buffer is still nil. How could I set it to t in w3m major mode?
Major modes have a hook variable for this sort of thing. Look for w3m-mode-hook.
(defun my-w3m-hook nil
(setq w3m-lnum-mode t))
(add-hook 'w3m-mode-hook #'my-w3m-hook)
The indirection to hook a separate function is not absolutely necessary, but simplifies the management of the hook functionality (otherwise you'd have to restart Emacs or jump through several hoops to add something to an existing hook; now all you need to do is evaluate a new defun of the function called from the hook).
You can set a default like so:
(setq-default w3m-lnum-mode t)
For fine-grained control, use a hook as RNAer suggests. As far as I can tell though, this is not a normal local variable but a minor mode variable. You actually probably want to do (w3m-lnum-mode 1).
We use an internal scripting language (let's call it pkc), which allows for embedding C++ code. The C++ code segments are delimited by {{{ and }}} markers.
I create an emacs mode for this language, using Generic Mode and mmm-mode.
Here is what I got (stripped down non-essential parts for posting here):
(require 'generic-x)
(setq pkc-imenu-generic-expression
'(("macros" "^[ \t]*macro[ \n\t]+\\([a-zA-Z0-9_]+\\)" 1)
("functions" "function[ \n\t]+\\([a-zA-Z0-9_]+\\)" 1)
))
(require 'cc-mode) ;; for c++-mode
(require 'mmm-auto)
(setq mmm-global-mode 'maybe)
(define-generic-mode
'pkc-mode ;; name of the mode to create
'("//" ("/*" . "*/")) ;; comments are same C++ comments
'( ... ) ;; some keywords
'("\\.pkc$") ;; files for which to activate this mode
;; other functions to call
'((lambda ()
(mmm-mode 1)
(setq mmm-submode-decoration-level 2)
(setq imenu-generic-expression pkc-imenu-generic-expression)
(which-function-mode 1)
(c-initialize-cc-mode t)
(c-init-language-vars-for 'c++-mode)
(c-common-init 'c++-mode)
(c-update-modeline)
(message "pkc-mode[mmm] is on")))
"A mode for pkc source files" ;; doc string for this mode
)
(mmm-add-classes
'((embedded-c++
:submode c++-mode
:face mmm-default-submode-face
:front "{{{"
:front-offset -1
:back "}}}"
:back-offset 1)))
(mmm-add-mode-ext-class 'pkc-mode nil 'embedded-c++)
When I load the source file with embedded C++ code segments, they are highlighted somewhat less than what would have been if C++ mode was the major mode (that's not my problem, however). When the cursor in C++ code, the modeline changes to pkc/l[C++/l] (as expected).
The problem is, whenever I press TAB to indent a line, I get the error Wrong type argument: stringp, nil. When I turned on debugger, this is the stack trace I see:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
c-syntactic-skip-backward(nil nil t)
c-looking-at-decl-block(nil t)
c-guess-basic-syntax()
c-indent-line()
#[nil \302>\203)\212\303 \210\304\305x\210\303 \210\306 )i\306 X\203\"\307 !\202'\212\307 !))\20 \207" [indent-line-function column (indent-relative indent-relative-maybe) beginning-of-line "\n " nil current-indentation indent-line-to] 2 1908700 nil]()
c-indent-command(nil)
c-indent-line-or-region(nil nil)
call-interactively(c-indent-line-or-region nil nil)
Looking at the definition of c-looking-at-decl-block and particularly the call to `c-syntactic-skip-backward, I find:
(c-syntactic-skip-backward c-block-prefix-charset limit t)
Examining the first argument c-block-prefix-charset reveals that its value is nil. Doing the same from a plain C++ buffer shows a non-nil value. So, I suspect that C++-mode requires some initialization that's not being properly done.
So, my questions are:
What am I missing in the C++-mode initialization section in my implementation?
Am I using the right approach (combining generic-x and mmm-mode)? Is there a better approach?
I also see another error (File mode specification error) when I load the file, but I suspect the problem is the same or something similar.
Thanks for your time.
(Rewritten after the discussion in the comments, for any later visitors).
The setup in the question is basically fine, but to work with current c++-mode you need to use an updated version of mmm-mode. It's available at the GitHub project page and also at Melpa.
The relevant patches (one, two, three) added new entries to the value of mmm-save-local-variables, which mmm-mode uses to decide which local variables to save or restore when leaving or entering a submode region.
From what I understand, a future update to cc-mode can add more such vars, so the list may need to be updated from time to time.
Extra tip: to have better indentation in the subregions, you may want to wrap the submode's indent-line-function with some code that will narrow the buffer before calling it (example here). Depending on the indentation function (and whether it calls widen), it may or may not help.