This question may be a duplicate of this question, but I can't get the following to work properly in my emacs.
I am trying to enter minor mode mlint-mode whenever I enter major mode matlab-mode (both modes available at their SourceForge page). I have the following in my .emacs file:
(add-hook 'matlab-mode-hook
(function (lambda()
(mlint-mode))))
which looks like the answer to the question I linked above. When opening a .m file, I get the following error:
File mode specification error: (void-function mlint-mode)
Could someone please assist in helping me write the correct hook to enter mlint-mode when I open a .m file? FWIW, I'm running emacs 23.1.50.1.
I think the correct name is mlint-minor-mode. Also, remember to ensure that all matlab stuff is known by Emacs, this can be done using:
(require 'matlab-load)
As a side note, it is typically a bad idea to use lambda functions in hooks. If you inspect the value of the hook you will see a lot of unrelated things. Also, if you modify your lambda expression and re-add it, both the old and the new version will be on the hook.
Instead, you can do something like:
(defun my-matlab-hook ()
(mlint-minor-mode 1))
(add-hook 'matlab-mode-hook 'my-matlab-hook)
The "1" is ensures that mlint mode is turned on or stay on if enabled earlier.
Related
After installing pdf-tools the dired mode opens the pdf file with PDFView mode as major mode.
(use-package pdf-tools
:ensure t
:config
(pdf-tools-install t))
How does the pdf-tools package be able to accomplish this?
The Help for RET key in dried buffer says it is bound to dired-find-file
RET (translated from ) runs the command dired-find-file (found
in dired-mode-map), which is an interactive compiled Lisp function.
I searched for dired-find-file in pdf-tools installed elisp files and could not find any advice-add's?
Also please explain how can one go about finding arbitrary key bindings like this one?
What it modified is not directly related to dired, but to how Emacs decides to open files in general. The part of the code that is responsible for that is in pdf-tools-install-noverify, itself called by pdf-tools-install. The first two lines of the function are:
(add-to-list 'auto-mode-alist pdf-tools-auto-mode-alist-entry)
(add-to-list 'magic-mode-alist pdf-tools-magic-mode-alist-entry)
the relevant variables pdf-tools-<auto/magic>-mode-alist-entry being constants defined earlier in the file pdf-tools.el.
You can check the relevant documentation for auto-mode-alist and magic-mode-alist, but to sum up, the former is a mapping from "filenames" (or more precisely, file patterns -- typically, regexps matching file extensions) to major modes, and the latter is a mapping from "beginning of a buffer" to a major mode (see also this wikipedia page on magic numbers/file signatures).
As to how one can determine that: because it is not directly related to key bindings/advices/redefinition of functions, the only "general" option is to explore the "call stack" ! The package tells you to put (pdf-tools-install) somewhere in your init file to activate the package, so you can try to see what this function actually does -- and going a bit further, you see that it is essentially a wrapper around pdf-tools-install-noverify, which does the real job of setting everything up.
I updated a lot of packages that I had directly from github to the MELPA packages. Nonetheless something really weird happened to my *scratch* buffer. The default message is not appearing (the buffer is completely empty), and also the interactive elisp mode is not set (let's say I write (+ 2 2) and then hit C-j and it tells me invalid function). I have no idea why. I don't even know how to debug it to check where the error is. Any ideas?
Finally the problem was generated by flycheck-add-next-checker, for some reason, using the MELPA repositories is generating this error. I just commented the following part of my configuration file.
(eval-after-load 'flycheck
'(progn
;; Add Google C++ Style checker.
;; In default, syntax checked by Clang and Cppcheck.
(flycheck-add-next-checker 'c/c++-clang
'(warnings-only . c/c++-googlelint))))
I'm trying to get doremi working in emacs. Specifically, at this stage, to allow me to quickly scroll through a condensed list of color-themes and see each theme as I go through it. For this I would use the 'M-x doremi-color-themes+' command.
What I've done:
Installed color-themes (successfull)
Installed doremi.el, doremi-cmd.el, ring+.el and added
(add-to-list 'loadpath "~/elisp/themes")
(add-to-list 'loadpath "~/elisp/doremi/")
(require 'color-theme)
(color-theme-initialize)
(color-theme-classic)
;; create a list of color themes to scroll through using 'doremi-cmd
(setq my-color-themes (list 'color-theme-classic
'color-theme-retro-green
'color-theme-gray30
'color-theme-subtle-hacker
'color-theme-jonadabian-slate))
(require 'doremi)
(require 'doremi-cmd)
(require 'ring+)
to the .emacs file.
What emacs does:
When I type the comand 'M-x doremi-color-themes+' into the mini-buffer it seems to accept that I've given it a valid command and tells me to use the and arrow keys to move through the list. But when I do that all that happens is the cursor moves up and down in the active window. No changing of color-themes.
Being somewhat new to emacs (and especially customising it) I'm sure I have missed a step or put something in the wrong place. Perhaps there's some sort of (setq 'bla-bla-bla (...)) I need to do?
Sorry for your trouble. Please state your Emacs version (M-x emacs-version), and your version of color-theme.el.
You do not need to require library ring+.el if you use Emacs 23 or later (its code was included in GnuEmacs 23.)
You do not need to use (color-theme-initialize) or (color-theme-classic). The former is done automatically by doremi-color-themes+.
Try starting from emacs -Q (i.e., no init file, ~/.emacs), to be sure there is no interference from stuff in your init file.
Your variable my-color-themes is not referenced anywhere. Instead of defining that variable, just customize user option doremi-color-themes. (Or leave its value nil, which means that all color themes will be cycled through.)
Feel free to contact me by email if you continue to have a problem. Or continue here, if you prefer.
[Just to be sure: you are using color-theme.el, right? There is a lot of confusion out there between Emacs "custom themes" and color themes. Do Re Mi supports both, but they are different critters.]
After a bit for back and forth with #Drew we found a solution to the problem.
It turned out the major problem was that I was using emacs in 'terminal mode' rather than as a GUI application. Bare in mind I'm using a mac.
In the context of Terminal, my arrow keys send escape sequences and so doremi cannot read the event as intended. So it just escapes and applies the message to the active buffer.
There is an answer.
By adding the following lines to my .emacs file (or whatever your init file for emacs is) I was able to redirect doremi to use two other keys. ie. not the up and down arrows.
(setq doremi-down-keys '(?n))
(setq doremi-up-keys '(?p))
Doing this tells doremi to use 'n' as the down key and 'p' as the up key. And all works just fine.
Because I am only new to the world of programming and computing I may often use incorrect terminology. If this is the case please let me know and I will edit accordingly for clarity and consistency.
I have noticed, from a while, that every time I run emacs in multi-web-mode I get the following message:"Toggling multi-web-mode off; better pass an explicit argument".
Why do I get that? multi-web-mode is not toggled off because I use it and it works fine, but I keep getting this message all the time.
How can I fix this little trouble?
This is my code in my .emacs file where "multi-web-mode" appears (I am using Emacs 23.4):
(require 'multi-web-mode)
(setq mweb-default-major-mode 'html-mode)
(setq mweb-tags '((c++-mode "<\\?php\\|<\\? \\|<\\?=" "\\?>")
(ecmascript-mode "<script +\\(type=\"text/javascript\"\\|language=\"javascript\"\\)[^>]*>" "</script>")
(css-mode "<style +type=\"text/css\"[^>]*>" "</style>")))
(setq mweb-filename-extensions '("php" "htm" "html" "ctp" "phtml" "php4" "php5"))
(multi-web-global-mode 1)
(add-to-list 'auto-mode-alist '("\\.php\\'" . multi-web-mode))
(add-to-list 'auto-mode-alist '("\\.html\\'" . multi-web-mode))
Well it sounds like somewhere there's some code causing this mode to be called, non-interactively, with no arguments: (multi-web-mode). A common cause would be specifying a mode function symbol for use as a callback, rather than specifying a function which will call that mode function (with an argument).
This certainly used to be bad form, as it would indeed act as a toggle, just as it does in the interactive case (e.g. M-x multi-web-mode). Since Emacs 24, however, it is actually safe to do (at least for modes defined with the standard macros), as a non-interactive call with no argument to a mode function now always means 'enable'. This might account for the fact that you're not actually seeing a problem.
I don't think stock Emacs has ever generated such a message, so I would presume it's multi-web-mode itself which is detecting and reporting on this. It may need to be updated to reflect the change in Emacs 24. (Edit: looks like I was wrong about that; I guess Emacs 23.4 did produce this warning.)
Your simplest fix is probably to show us any lines from your config which mention multi-web-mode, so someone can show you how to change it to ensure that it passes an explicit argument (which is typically 1 to enable a mode).
Edit: Okay, your problem is that multi-web-mode is a minor mode (as opposed to a major mode), but you have specified it in auto-mode-alist which is a mechanism for mapping filename patterns to major modes.
So the cause is exactly as I suggested above when I said "A common cause would be specifying a mode function symbol for use as a callback", as those auto-mode-alist entries will result in a call to (multi-web-mode).
It appears to me that multi-web-global-mode handles enabling the minor mode as required, so you just need to remove the bad auto-mode-alist entries.
I have a strange interaction with tramp and cygwin-mount (I think: Emacs: Tab completion of file name appends an extra i:\cygwin). Because of this, I want to disable tramp. I'm unable to find anything in my .emacs which is loading tramp explicitly. I can see "Loading tramp..." when I hit a tab in the find-file minibuffer. I'd like to figure out what package is causing the loading of tramp and disable that. How do I go about doing this? I tried searching for (require 'tramp) but couldn't find anything interesting. The only other option I can think of is to comment out bits of my .emacs one-by-one and see which one works - but this is so brute-force, I'd like a cleverer (and easier) way.
What a great question! If only because I was not aware of the function (eval-after-load file form) which will enable you to write code like the following and put it in your .emacs file:
(eval-after-load "tramp"
'(debug))
Which will, in brute force form, vomit a backtrace in your window and reveal the offending library.
I think you'll find that tramp is turned on by default. If you do:
M-x customize-apropos
Customize (regexp): tramp
('Customize (regexp):' is the prompt from emacs) you'll see two variables listed (at least I do in emacs 23), something like:
If you set tramp-mode to 'off', save for future sessions, and restart emacs tramp should no longer be loaded. I believe you can just turning it off in the current session should allow you to test this, but this doesn't always work with customize variables, although it should do with something like tramp that is part of the standard emacs distribution.
I don't have emacs 22 installed any more, but something similar should work for that too.
I had a similar problem with tramp, when one day I found
"/C:\...\debuglog.txt" on my system.
Because of that file, auto-complete was invoking tramp each time
I entered "/". And tramp was of course giving an error.
auto-complete was calling
(expand-file-name ...)
which, because of the current file-name-handler-alist, was calling tramp.
My solution was:
(delete-if
(lambda (x)
(or (eq (cdr x) 'tramp-completion-file-name-handler)
(eq (cdr x) 'tramp-file-name-handler)))
file-name-handler-alist)
Instrument find-file for debugging and/or instrument your init file for debugging. Then you can step through the loading and see where the tramp stuff is loaded.