featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
Moved add-hook calls (for tree-sitter initialization) into their
respective modes' config blocks, or nearby, to be consistent with how
other, similar tools (like lsp!) are initialized, and does so at
runtime, rather than at expansion/compile time, which eval-when! caused.
BREAKING CHANGE: break the global nature of the tree sitter
module by adding a +tree-sitter flag to every applicable module
In the background this hooks turn-on-tree-sitter-mode
to the major-mode-hook of the language.
This may also solve the eager loading of tree sitter
Ensime just went missing from everywhere.
On [[ensime.github.io]], they encourage to switch to metals -
a new Scala language server already supported by lsp-mode.
This commit:
- removes ensime completely
- adds a doctor.el to check for metals-emacs binary
Original issue: 6288099561
Metals: https://scalameta.org/metals/docs/editors/emacs.html
Calling this pivotal macro "def-package!" has frequently been a source
of confusion. It is a thin wrapper around use-package, and it should be
obvious that it is so. For this reason, and to match the naming
convention used with other convenience macros/wrappers, it is now
use-package!.
Also changes def-package-hook! -> use-package-hook!
The old macros are now marked obsolete and will be removed when straight
integration is merged.
Still needs to be documented, but includes support for the following
languages:
+ C/C++/ObjC
+ Go
+ Java
+ Javascript
+ OCaml
+ PHP
+ Python
+ Ruby
+ Scala
+ Swift
+ HTML/CSS
Relevant to #460, #716, #1186
+ :popup -> set-popup-rule!
+ :popups -> set-popup-rules!
+ :company-backend -> set-company-backend!
+ :evil-state -> set-evil-initial-state!
I am slowly phasing out the setting system (def-setting! and set!),
starting with these.
What are autodefs? These are functions that are always defined, whether
or not their respective modules are enabled. However, when their modules
are disabled, they are replaced with macros that no-op and don't
waste time evaluating their arguments.
The old set! function will still work, for a while.
Now that we are loading package autoloads files (as part of the
generated doom-package-autoload-file when running make autoloads), many
:commands properties are redundant. In fact, many def-package! blocks
are redundant.
In some cases, we can do without a config.el file entirely, and can move
into the autoloads file or rely entirely on package autoloads.
Also, many settings have been moved in their module's autoloads files,
which makes them available ASAP; their use no longer depends on module
load order.
This gained me a modest ~10% boost in startup speed.
+ Autoload ensime after scala-mode
+ Don't let ensime initialize company; let :company-backend do it
+ Fix void-variable imenu-auto-rescan error caused by
ensime--setup-imenu.
+ enable lexical-scope everywhere (lexical-binding = t): ~5-10% faster
startup; ~5-20% general boost
+ reduce consing, function calls & garbage collection by preferring
cl-loop & dolist over lambda closures (for mapc[ar], add-hook, and
various cl-lib filter/map/reduce functions) -- where possible
+ prefer functions with dedicated opcodes, like assq (see byte-defop's
in bytecomp.el for more)
+ prefer pcase & cond (faster) over cl-case
+ general refactor for code readability
+ ensure naming & style conventions are adhered to
+ appease byte-compiler by marking unused variables with underscore
+ defer minor mode activation to after-init, emacs-startup or
window-setup hooks; a customization opportunity for users + ensures
custom functionality won't interfere with startup.
