Is there a way to require multiple conditions in a use-package :hook? - emacs

I'm using use-package in my literate init.el, and I'm in the process of learning Evil Mode. As such, I don't always use it, but I will often turn it on while working on code or Org files, and turn it off for Markdown.
What I'd like to do is automatically turn on Evil-Org when Evil mode is invoked inside a buffer in which Org mode is active. If I turn on Evil mode in a non-Org mode buffer, Evil-Org should not turn on. I've seen other StackExchange threads like this one, except the hooks are evaluated with an OR instead of an AND.
Currently I have
(use-package evil
:ensure t
:defer t
:hook (org-mode . evil-org-mode)
:config
;; config goes here
)
(use-package evil-org
:after evil
:ensure t
:defer t
)
My logic is that the defer in the Evil package config will prevent it from loading, but when it does the hook will be evaluated so that if I'm in a buffer with Org Mode active, evil-org-mode will also become active, but this does not happen.
Thanks!

Related

emacs + clojure-mode: add multiple hooks

This is a part of my init.el file, which enables one hook to the clojure-mode:
(use-package clojure-mode
:ensure t
:config (add-hook 'clojure-mode-hook #'aggressive-indent-mode))
What is the syntax for enabling multiple hooks (e.g. #'paredit-mode and maybe more)?
As #ArthurUlfeldt points out, you can add multiple add-hook statements, one for each of the hook functions you want to add. However, this can become a little tiresome when you have a common set of things you want to add to multiple modes.
For example, if you use a number of lisp like languages, then you might want to add paredit, aggressive-indent, eldoc, rainbow-delimiters etc to each of these modes. Rather than having to sprinkle lots of add-hook commands all through your init file, you can define your own function i.e. my-lisp-hook which calls all the init functions you were adding with individual add-hook commands. Then you just need to do an add-hook which calls your function.
The other advantage this can have is it makes adding/removing something like a new minor mode much easier. For example, if you had
(defun my-lisp-hook ()
(paredit-mode 1)
(aggressive-indent-mode 1)
(raindbow-delimiter-mode 1))
and then had
(add-hook 'emacs-lisp-mode-hook 'my-lisp-hook)
(add-hook 'lisp-mode-hook 'my-lisp-hook)
(add-hook 'clojure-mode-hook 'my-lisp-hook)
(add-hook 'cider-mode-hook 'my-lisp-hook)
and then after an ELPA package update found the new version of aggressive-indent-mode was causing problems, you could just comment out 1 line in your my-lisp-hook function to stop the call to aggressive-indent-mode and get back to work. On the other hand, if you had added it separately in each mode hook, you would hve to comment out 4 lines. It also keep things consistent. I have run into subtle issues when I've loaded minor modes in one order for one mode and a different order for a different mode. With the use of your own hook function to load common setup requirements, it all happens consistently.
Note that the above code is pseudo code and is not meant to actually run. I don't know if the command to turn on rainbow delimiters is rainbow-delimiters-mode 1 or if the right hook to use for lisp mode is lisp-mode-hook. My examples are merely done to demonstrate the concept.
the way you write your emacs init file is a personal choice, but I think you should apply the same sort of rules we all know should be applied to writing code. Two of which are 'do not repreat yourself' and 'write your code to be clear rather than clever'. I think we shold apply the same logic to our emacs init file.
I also think your off to a great start with use-package. I've just switched to using it and think it is a great way to help structure your init file. However, to get the most out of it, especially with respect to delayed loading of packages so that my startup time is reduced, I did find I had to restructure my init file a fair bit. This could simply be a sign my original structure wasn't that good or it could be a sign of my current interest in trying and tweaking my emacs config as a bit of a hobby/distraction from cutting real code, whih tends to result in a less structure init due to the constant change.
you can add multiple statements after the :config keyword:
(use-package clojure-mode
:ensure t
:config (add-hook 'clojure-mode-hook #'aggressive-indent-mode)
(add-hook 'clojure-mode-hook #'other-thing-here)
(yas-global-mode 1))
Here's a chunk from my config:
(use-package cider
:ensure t
:config
(define-key cider-mode-map (kbd "C-c SPC") 'avy-goto-word-1)
(define-key cider-mode-map (kbd "C-x SPC") 'avy-pop-mark))

Emacs: Disable auto-fill minor mode when in idlwave major mode

In Emacs how do I stop the auto-fill minor mode from loading when I start the idlwave major mode?
So far I have been completely unsuccessful at figuring out how to do this. I have tried to use remove-hook for both idl-mode-hook and text-mode-hook without success.
You might have enabled auto-fill-mode as a global minor mode, so it is on in all buffers by default. If that is the case, the task is not so much not turning it on in idlwave-mode but rather turning it off.
Most major modes provide a special hook variable: it's a list containing functions that are called whenever that major mode is invoked. For instance, with the following line you can make sure that auto-fill-mode will get turned off each time a buffer goes into idlwave-mode:
(add-hook 'idlwave-mode-hook (lambda () (auto-fill-mode 0)))
Put the above line in your init file (e.g. ~/.emacs or ~/.emacs.d/init.el) and auto-fill-mode should be turned off in idlwave mode after you restarted Emacs.

In Emacs, how to disable auto-fill-paragraph mode when in php-mode?

Normally, I need to enable the auto-fill-mode, so I have it turned on in .emacs. But when editting PHP in php-mode, I'd like to not use auto-fill-mode. Is there way to set it in .emacs such that when I'm in PHP mode, the auto-fill-paragraph mode is automatically turned off and when I leave php-mode, it's automatically turned on, barring other overriding?
Update: a closer examination of the .emacs revealed that auto-fill is set up by
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(column-number-mode t)
...
'(text-mode-hook (quote (turn-on-auto-fill text-mode-hook-identify)))
...)
Some major-modes inherit certain settings from other modes (e.g., text-mode is used by many popular major modes). The following code snippet can be used to disable a feature for a particular major-mode using its mode hook:
(add-hook 'php-mode-hook (lambda ()
(auto-fill-mode -1) ))
It is sometimes helpful to check and see whether a particular feature has been enabled globally or locally, which in turn can give a clue as to whether that feature has been inherited by a major mode. In this case, the documentation for auto-fill-mode states as follows -- https://www.gnu.org/software/emacs/manual/html_node/emacs/Auto-Fill.html:
"Auto Fill mode is a buffer-local minor mode (see Minor Modes) in which lines are broken automatically when they become too wide. Breaking happens only when you type a <SPC> or <RET>."

How to use emacs tuareg mode effectively to manage an OCaml project? [duplicate]

Do you know of a good project tree browser for Emacs other than the Emacs Code Browser (ECB)? The features I value are simplicity, lightweightedness, and language agnosticism.
Projectile + NeoTree are my combination of choice.
Projectile just uses your version control system to track files and has an awesome jump to file in project function.
Also, check the notes for integrating the two together.
Speedbar?
If you just want to manage related files, perhaps you would like eproject.
I haven't tried this one myself yet, but emacs-nav is a new Emacs project browser from Google that seems to have the features you value.
You can try sr-speedbar. It's wonderful.
The different parts of cedet will do what you want I think. Speedbar has the tree structure thing, and EDE handles projects etc.
I just now did a word search for "explore" in package-list-packages, and discovered project-explorer. Seems to fit exactly what I want today (I don't code hardly, but I'm getting a grip on the structure of my Jekyll site).
Keys include:
TAB for folding and unfolding directories
Open files with RET or f. With a C-u prefix, it will prompt nicely for which window, and even from there allow you to decide to use window or open up a new one to any side (I didn't find the prompt string in the package code, so it seems to leverage built in Emacs functionality nicely; indeed it looks like dired even).
It's available on Melpa and Marmalade. It is available on Github at sabof/project-explorer.
I include the site's image for convenience:
I don't use projectile or helm, but it has some integration.
Here are my thoughts on several competing file explorer type packages. See the comments above each package below:
;; Dired itself allows one to do 'i' to insert (display in same buffer) the
;; subdirectory under point and C-u k on subdir header line to remove. However,
;; I have found that dired-subtree-toggle and dired-subtree-remove are a better solution for the removal
;; part. Plus dired-subtree let's you customize colors of subdirs to set them apart
;; visually. However, I set all depths of subdirectories custom faces to be the same as I found it distracting.
(use-package dired-subtree
:ensure t
:bind (:map dired-mode-map ("i" . 'dired-subtree-toggle))
:bind (:map dired-mode-map ("I" . 'dired-subtree-remove)))
;; This works nicely. It provides the parent, '..', directory unlike nav.
(use-package project-explorer
:ensure t
:config
(evil-set-initial-state 'project-explorer-mode 'emacs))
;; This can't go above the directory you started it in. It is nice, but I prefer the flexibility
;; of getting to parent directories in most cases.
(use-package dirtree
:ensure t)
;; Google's file explorer
;; Nice, but doesn't maintain visited nodes in view, preferring instead to offer only
;; the current directory or lower in a side window. No better than ivy which is my main file explorer system.
(use-package nav
:ensure t)
;; This is buggy on Emacs 26.1.
(use-package eproject
:disabled t
:ensure t)
;; speedbar is included with Emacs (since 24.x I believe). It has to use a separate frame, which is
;; inconvenient most of the time. There are better options (above).
;; (use-package speedbar)
;; Buggy; doesn't work on Emacs 26.1 (at least with my config).
(use-package sr-speedbar
:disabled t
:load-path "../lisp")
;; Buggy on Emacs 26.1 (at least with my config). I couldn't even get it to activate.
(use-package ecb
:disabled t
:ensure t)
;; Nice, but similar to ivy which I've already committed to, so not necessary.
(use-package lusty-explorer
:disabled t
:ensure t)
For me, ivy plus dired gets me 98% of the way. ivy, dired, and dired-subtree gets me 99% of the way. project-explorer, and to a lesser extent, nav, are just nice alternatives to ivy plus dired or ivy plus dired and dired-subtree. Hopefully this will save you some time.
I've used treemacs and it's works good, esp. with projectile.

Almost-global Emacs minor mode

I'm working on an Emacs minor mode, and I'd like it to apply only when the major mode is a certain mode (i.e. js-mode). In other words, when I activate my-super-mode, I'd like the keymap it defines to be available in all JS buffers (like it was global) but without affecting non-js buffers.
I know it's possible via hooks but I'd like to avoid this solution. Ideally my minor mode would be activated only when needed via M-x (and when activated it should be in effect in all JS buffers). Possible?
One solution that comes to mind is to define a buffer-local minor mode that implements the actual functionality, but is not invoked directly by the user and its name prefixed by an internal prefix to prevent accidental triggering:
(define-minor-mode my--mode
"Mode implementing blah, invoke it with M-x my-super-mode."
nil " Super" nil
;; mode definition goes here, including keymaps, etc.
)
The public mode invoked by the user is global. When switched on or off, it automatically switches the internal mode in all existing and future JS buffers:
(defun my--mode-set-maybe ()
(my--mode (if my-super-mode 1 0)))
(define-minor-mode my-super-mode
"Super mode, only in effect in JS buffers."
nil "" nil
:global t
(dolist (buf (buffer-list))
(with-current-buffer buf
(my--mode-set-maybe))))
(add-hook 'js-mode-hook 'my--mode-set-maybe)