✨ Future-proof your Emacs Lisp customizations!
el-patch-feature after the feature name are no longer quoted by el-patch-feature before being passed to el-patch-require-function. This means you can write them as normal function arguments instead as unquoted symbols.el-patch-require-function has changed from require to el-patch-default-require-function, which ignores all arguments to el-patch-feature aside from the feature name, and converts require errors to warnings (#47).el-patch-variant. For advanced usage. See #29 for discussion.el-patch-validate-during-compile to non-nil (#48).el-patch forms are now fontified the same way as their built-in counterparts, e.g. the function name in an el-patch-defun is fontified the same as the function name in a defun would be. See #35.el-patch has changed, reducing
the amount of work that is done at startup and simplifying the
implementation (#56). The user-facing impact is as follows:
el-patch--patches and el-patch-deftype-alist are no longer autoloaded. If you use a compiled init-file, you may need to recompile it with the new version of el-patch; the code compiled with the old version of el-patch will not work at runtime with the new version of el-patch. However, evaluating patches in a compiled init-file, even one that uses el-patch-deftype, still does not load el-patch.el-patch-defun and analogous functions are now autoloaded, rather than fully defined at init time. This should not matter since a compiled init-file would have macroexpanded these into smaller components that do not have runtime dependencies on el-patch.el-patch-stub.el that needs to be on the load-path for autoloads to work. This should be taken care of automatically by any of the popular Emacs package managers.el-patch-validate-all will proceed to check other patches before reporting the error, rather than crashing immediately (#46).el-patch-cl-defun (#39).el-patch-ediff-patch and el-patch-ediff-conflict the compared buffers are put into emacs-lisp-mode automatically to enable syntax highlighting and Lisp navigation.Under some circumstances, users received the error message
Unregistered definition type ‘defalias’
when evaluating an el-patch form. The problem could be worked around by explicitly require-ing el-patch before the form underwent macroexpansion. However, it should now be impossible to get that error regardless of whether el-patch was loaded previously (#30).
el-patch automatically adds a note to the docstring so that you know a patch is in effect. Previously, this behavior was suppressed if the modified definition did not contain a docstring at all; now, the note is included regardless, adding a docstring if one was missing (#31).This release includes only a minor documentation enhancement.
el-patch-concat may be used to modify string literals in a patch without repeating their contents twice (#14).el-patch-defun for your own definition types using the new el-patch-deftype macro, which operates on the new user option el-patch-deftype-alist (#24).el-patch now provides integration with use-package, controlled by the variable el-patch-enable-use-package-integration and the minor mode el-patch-use-package-mode. Two new keywords, :init/el-patch and :config/el-patch, are defined (#25).el-patch now automatically appends a note to the end of the docstring indicating that a patch was made (#14).el-patch-let now allows more than one body form; all body forms are spliced into the containing s-expression. This is fully backwards compatible.el-patch-literal always allowed more than one body form, but this fact is now documented.Using el-patch-let could previously cause a circular list error. For example:
(el-patch-let ((x y)) (x x x))
That has now been fixed.