I am doing small modification to SLIME, so that I can get all currently loaded symbols from Lisp, analyze them and make font-lock fontify them.
I managed to do all these steps, but I have a small problem - when keyword list changes in font-lock the buffer is not updated unless you restart the major lisp-mode. I don't want to restart lisp-mode every time I update keywords, because I have several hooks on lisp-mode that I want to run only when I load the file for the first time.
Is there an other way to update font-lock so it reads all then new keywords and fontifies the buffer accordingly? Switching off font-lock and using font-lock-fontify-buffer does not do the trick.
UPD: Added bounty - the question is still up. I need a way to reload font-lock keyword without reloading major mode.
Ok, how about this instead:
(defun my-font-lock-restart ()
(interactive)
(setq font-lock-mode-major-mode nil)
(font-lock-fontify-buffer))
You could temporarily clear the mode hook variable and restart it:
(defun my-restart-lisp-mode ()
(interactive)
(let ((lisp-mode-hook nil))
(normal-mode)))
Triggering the major-mode is not what makes font-lock do its thing. I am not intimately familiar with the internals of SLIME or lisp-mode, but just setting the variable should make it work. Toggling font-lock-mode will make font-lock start refontifying with the new keywords in mind, as should font-lock-fontify-buffer.
I hack on cperl-mode, mostly, and it is a simple matter of cperl-init-faces (which sets the internal font-lock variables) and a restart of font-lock. lisp-mode should not be much different, except for not needing a call to cperl-init-faces ;)
Edit: some experimentation with lisp-interaction-mode reveals that even restarting font-lock-mode is not strictly necessary. Just changing font-lock-keywords is enough, as long as you re-trigger fontification somehow. (Editing text, font-lock-fontify-buffer, etc.)
Related
the guys of the plain tex-mode have added a very nice feature with emacs 24.1, a minor mode called latex-electric-env-pair-mode which keeps existing \begin{...} [...] \end{...} pairs matched. I.e. when changing the environment name in the \begin{...} tag, its corresponding \end{...} is changed automatically (very nice when changing from starred to non-starred version of an environment and vice-versa).
However, when comparing with AUCTeX, the tex-mode still sucks... but I really like the new minor mode. I have tried to make a stand-alone minor mode by copying everything that looked like it was used from tex-mode.el to a new file and changed all the descriptors (so they won't conflict with AUCTeX or any remainders for tex-mode). Unfortunately this won't work, the minor mode can be turned on but it is broke: nothing is happening.
I'm not a (e)lisp programmer, that is to say I don't really understand the code. But maybe someone likes the feature of this minor mode and can port it to a stand-alone version?
Also there might be some package out there which provides similar/equal functionality?
I'd appreciate any help!
You probably missed tex-env-mark (which sets marks that are used later by latex-electric-env-pair-mode to find environment starters/enders) or latex-syntax-propertize-rules (which runs tex-env-marks on relevant parts of the buffer) or the setting of syntax-propertize-function (which uses latex-syntax-propertize-rules so that these rules are actually used).
BTW, rather than copying those things, I recommend you try something like the untested code below:
(defconst my-latex-syntax-propertize-function
(with-temp-buffer (latex-mode) syntax-propertize-function))
(add-hook 'LaTeX-mode-hook
(lambda ()
(set (make-local-variable 'syntax-propertize-function)
my-latex-syntax-propertize-function)
(latex-electric-env-pair-mode 1)))
Goal: I want to have show-trailing-whitespace enabled for all buffers save a few. Exceptions posing a problem are *Shell Command Output* and its cousin *Async Shell Command*.
I usually have show-trailing-whitespace customized to t. Therefore it is active in all new buffers.
I would also like to have it turned off for certain buffers, foremost amongst them *Shell Command Output*. This poses a problem for me:
The output buffer doesn't use a special mode; it is still in fundamental-mode. There is no fundamental-mode-hook that I could hook this setting into.
There is the after-major-mode-change-hook which is run when the major mode is changed to fundamental-mode, but the buffer starts out in that mode and therefore this hook is not run.
There doesn't seem to be a way to hook into get-buffer-create.
I know I can always advise the function get-buffer-create for this particular example, but I try to avoid that as much as possible.
Any hints?
You might be better off looking at the problem from the other side, and only set the var in those modes where you want to see trailing whitespace.
But I think you have a good point: these shell output buffers should not use fundamental-mode. It's probably time for M-x report-emacs-bug
In accordance with the accepted answer, here's a code snippet that enables trailing whitespaces highlighting for specific modes only:
(setq-default show-trailing-whitespace nil)
(defun namespace/show-trailing-whitespace ()
"Highlight trailing whitespaces in this buffer."
(setq-local show-trailing-whitespace t))
(dolist (hook '(prog-mode-hook text-mode-hook))
(add-hook hook 'namespace/show-trailing-whitespace))
This snippet is essentially taken from Steve Purcell's configuration.
I am using GNU Emacs 22.3.1 on Windows.
In my Emacs I have enabled delete-selection-mode, and it's very useful to select a region and delete or replace it. But I have a drawback.
When I write or press DEL over the selection, Emacs does not only remove the text, but it kills (a.k.a. send to the clipboard*). This is very annoying for me, because I don't have control of my kill-ring (a.k.a. clipboard) and may cause unexpected effects.
There is a way that delete-selection-mode does not kill the text, just delete it? Perhaps modify the source code?
(*: I have synchronized the kill-ring and the Windows clipboard, so for me (for practical purposes) it's the same)
Edit[Jun 24, 2009]
Thanks, danielpoe. Even with the idea of Trey Jackson the selection is still killing. And I found the reason.
I discovered that the problem was not in delete-selection-mode. The problem is, when I selected the region, I did it with the mouse. And never have imagined that it was the mouse who was copying the text. Using the set-mark command and the arrow keys the text finally aren't killed, only deleted.
I disabled this behavior writing this in my .emacs:
(require 'delsel)
(setq mouse-drag-copy-region nil)
(global-unset-key (kbd "<mouse-2>"))
(global-unset-key (kbd "<mouse-3>"))
Thanks for the advice. If this method of disable this mouse behavior can cause conflicts with other options, please comment.
Have you tried starting emacs with -Q. If I do so and only enable M-x: delete-selection-mode, I can't reproduce what you describe. Nothing is killed only deleted?! Can you check?
It looks as though you just need to modify a small part of the source, namely make this change:
(defun delete-active-region (&optional killp)
(delete-region (point) (mark))
t)
The original code looked at the argument killp and used that to decide whether to add the region to the kill-ring, and you said you don't ever want that. This change forces the region to always be deleted.
Now, you don't need to actually modify the source, just place that function definition after the (require 'delsel) in your .emacs (or after the (delete-selection-mode)).
As a vim convert, I've gotten fairly used to viper mode. One issue that I've discovered, however, is that viper-auto-indent breaks all inferior modes. What happens is when I enter any sort of inferior mode (sql-mode, ess-mode, etc.) and hit Enter, the Enter key doesn't actually send the command off to the inferior process and gives the appearance of the process just hanging.
Without setting viper-auto-indent I have the problem that the Enter key doesn't automatically indent when writing code, meaning that I need to always hit tab after entering a new line, which is annoying. The workaround I've been using is to have viper-auto-indent enabled by default (since I spend most of my time programming), and then disabling it when I enter an inferior-mode buffer.
Does anyone know how to fix this problem? Alternatively, can anyone help supply me with the elisp to disable viper-auto-indent when switching to an interior mode buffer, and enabling it when in a non-inferior mode buffer? Thanks.
I think Emacs' intent is to have you use "C-j" for newline-and-indent, and let Enter be left alone.
If that is not yet acceptable to you, then this untested code may work:
(add-hook 'inferior-ess-mode-hook
'(lambda () (set (make-local-variable 'viper-auto-indent) nil))
I'm not able to reproduce your problem. I tried every level of viper-mode (1-5), and a number of inferior processes. That said, from your actual question, this code appears like it should fit the bill. If/when 'viper-autoindent is called, if the current buffer has a process, it calls the original binding for the keys just pressed. If there's no process, the original viper-autoindent is called.
(defadvice viper-autoindent (around viper-autoindent-but-not-when-buffer-has-process activate)
"work around reported user problem"
(if (and (this-command-keys)
(get-buffer-process (current-buffer)))
(let* ((viper-mode nil)
(thiskey (key-binding (this-command-keys))))
(when thiskey
(call-interactively thiskey)))
ad-do-it))
I've recently started using ido-mode, which, overall, is pretty nice. But one thing seems especially broken, and I'm wondering if there's a setting (ha) buried in there to fix it.
ido-switch-buffer doesn't seem to care about buried buffers. That is, if I use bury-buffer, and then ido-switch-buffer, the first choice is often the one I just buried.
Is there an easy way around this? The whole point of burying a buffer is that I don't want to see it again any time soon.
Acording to the documentation (C-h f bury-buffer)
Put BUFFER-OR-NAME at the end of the list of all buffers.
There it is the least likely candidate for 'other-buffer' to return;
thus, the least likely buffer for C-x b to select by
default.
So, if you use bury-buffer the buffer will be still available (at the end of the list), so it's normal that ido-switch-buffer find it.
If you don't want to see that buffer ever, you should think of closing it.
I can't reproduce this. On Emacs 23, as far as I can tell, ido-switch-buffer lists the buffers in the correct order.
In any case, you might try out iswitchb instead. It's kind of like ido, only older and more specific to buffer switching. If you like it, you can use iswitchb for buffer switching and ido for everything else.
can't reproduce this either: when i bury a buffer and call ido-switch-buffer afterwards, the buried buffer is NOT at the front of the switch list.
i have done quite a bit of ido customization (to get it working well with dired, etc), but my main ido settings are:
(setq ido-show-dot-for-dired t)
(setq ido-default-file-method 'samewindow)
(setq ido-default-buffer-method 'samewindow)
(setq ido-confirm-unique-completion t)
(setq ido-max-dir-file-cache 20)
my ido.el version is "1.57 released on gnu.emacs.sources adapted for emacs 22.1".
hth.
Use next-buffer or previous-buffer
FWIW, the default completion behavior of switch-to-buffer (C-x b) in Emacs-24 has been changed to use substring-match completion, so its behavior is similar to IDO while obeying the principle that "the default buffer shouldn't be the one I just buried". You can make it even more similar by turning on icomplete-mode (which does not change the completion behavior itself, but displays the completion candidates at the end of the minibuffer).