All notable changes to this project will be documented in this file. The format is based on Keep a Changelog.
- New user option
el-patch-use-advicewhich can be customized to haveel-patchinstall patches using the built-in advice system instead of overwriting function definitions directly.
- Some minor improvements to the way errors are reported from
el-patch-template.
- The arguments to
el-patch-featureafter the feature name are no longer quoted byel-patch-featurebefore being passed toel-patch-require-function. This means you can write them as normal function arguments instead as unquoted symbols. - The default value of
el-patch-require-functionhas changed fromrequiretoel-patch-default-require-function, which ignores all arguments toel-patch-featureaside from the feature name, and convertsrequireerrors to warnings (#47). - Emacs 25 is no longer supported.
- You can define patch variants using the new variable
el-patch-variant. For advanced usage. See #29 for discussion. - You can validate patches automatically during byte-compilation by
setting
el-patch-validate-during-compileto non-nil (#48).
- All
el-patchforms are now fontified the same way as their built-in counterparts, e.g. the function name in anel-patch-defunis fontified the same as the function name in adefunwould be. See #35.
- The autoloading mechanism used by
el-patchhas 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--patchesandel-patch-deftype-alistare no longer autoloaded. If you use a compiled init-file, you may need to recompile it with the new version ofel-patch; the code compiled with the old version ofel-patchwill not work at runtime with the new version ofel-patch. However, evaluating patches in a compiled init-file, even one that usesel-patch-deftype, still does not loadel-patch.el-patch-defunand 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 onel-patch.- There is a new file
el-patch-stub.elthat needs to be on theload-pathfor autoloads to work. This should be taken care of automatically by any of the popular Emacs package managers.
- New way to patch elisp objects based on a partial template and the
original definition the object (#50). See the documentation on
el-patch-templatein the README.
- Patch forms were not processed when they appeared inside a vector. This has been fixed (#51).
- If a function is not defined, then
el-patch-validate-allwill proceed to check other patches before reporting the error, rather than crashing immediately (#46).
- New patch type
el-patch-cl-defun(#39).
- When using
el-patch-ediff-patchandel-patch-ediff-conflictthe compared buffers are put intoemacs-lisp-modeautomatically to enable syntax highlighting and Lisp navigation.
-
Under some circumstances, users received the error message
Unregistered definition type ‘defalias’when evaluating an
el-patchform. The problem could be worked around by explicitlyrequire-ingel-patchbefore the form underwent macroexpansion. However, it should now be impossible to get that error regardless of whetherel-patchwas loaded previously (#30).
- The user option
el-patch-use-package-modeis now correctly declared in the Custom groupel-patch, rather than the separate groupel-patch-use-package.
- When a definition is patched,
el-patchautomatically 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.
- The new patch directive
el-patch-concatmay be used to modify string literals in a patch without repeating their contents twice (#14). - You may now define functions analogous to
el-patch-defunfor your own definition types using the newel-patch-deftypemacro, which operates on the new user optionel-patch-deftype-alist(#24). el-patchnow provides integration withuse-package, controlled by the variableel-patch-enable-use-package-integrationand the minor modeel-patch-use-package-mode. Two new keywords,:init/el-patchand:config/el-patch, are defined (#25).
- When a definition is patched,
el-patchnow automatically appends a note to the end of the docstring indicating that a patch was made (#14).
el-patch-letnow allows more than one body form; all body forms are spliced into the containing s-expression. This is fully backwards compatible.el-patch-literalalways allowed more than one body form, but this fact is now documented.
-
Using
el-patch-letcould previously cause a circular list error. For example:(el-patch-let ((x y)) (x x x))That has now been fixed.
el-patchnow uses lexical binding.el-patchis now tested on all supported Emacs versions.el-patchno longer uses the deprecatedelinttesting framework.
el-patchcan now be used in your init-file without being loaded at runtime. In other words, the patch definition macros expand, at compile time, to code that does not referenceel-patch(#11).el-patchnow useselintto run its tests and stylistic checks. Lines longer than 80 characters now fail the build.el-patchforms now have a well-defined return value, namely the same as would have been returned by the corresponding non-el-patchform (#15).
el-patchpreviously failed with an error if you attempted to patch an object which used a literal cons cell or improper list in its definition. This has been fixed (#13).
el-patchnow has a Makefile for convenient byte-compilation, linting, and table-of-contents updating.el-patchnow checks for byte-compilation and checkdoc warnings on Travis CI (#7).- New macro
el-patch-feature(unrelated to the old obsoleteel-patch-featuremacro that was removed) which is a convenient way to add feature-requiring functions toel-patch-pre-validate-hook(#10). - New user option
el-patch-require-functionfor advanced users only. It allows you to integrateel-patch-featurewith your package manager, and other things like that.
- Deprecated patch directive
el-patch-featurehas been removed.
- Messages emitted by
el-patch-validate-allnow have correct pluralization (#9). - The documentation on
el-patch-validatewas not updated to reflect its new signature in version 1.1.1. This has now been fixed.
- Patches can now be defined for more types of objects:
el-patch-defconst
- Custom group for
el-patch. - New user option
el-patch-aggressive-defvarto allow overriding the existing value of a variable.
- Variables
el-patch-pre-validate-hookandel-patch-post-validate-hookare now Custom variables.
- Since version 1.1, the "But how does it work?" section of the README
contained an erroneous explanation implying that
setandfsetwere used to establish patched definitions. This has been replaced with a correct explanation.
- The function
el-patch-validatenow takes a patch name and type rather than a patch definition. The remaining argumentsNOMSGandRUN-HOOKShave not changed. - The meaning of the prefix argument has been inverted for
el-patch-validate. Now it runsel-patch-pre-validate-hookandel-patch-post-validate-hookby default, and only omits doing so if a prefix argument is provided.
- Since version 1.1,
el-patch-validatefailed with an error inel-patch--classify-definition-type. This has been fixed (#8). - Since version 1.1, if a patch was defined in the same file as the function it patched, the patch could not be validated. This has been fixed.
- Previously, when
el-patch-validatewas called noninteractively with a non-nil value forRUN-HOOKS, it failed to runel-patch-pre-validate-hook. This has been fixed.
- Patches can now be defined for more types of objects:
el-patch-defvarel-patch-defcustomel-patch-define-minor-mode
- New function
el-patch-getto get a patch definition by name. - Objects can now be renamed in a patch using
el-patch-swapon the name (#4). - Actual description in the Commentary section of
el-patch.el(#5). - MIT license (melpa/melpa#4512).
- Arbitrary functions can be run (to load patches) by adding things to
the new hook
el-patch-pre-validate-hook. Cleanup can then be done inel-patch-post-validate-hook.
- It is no longer necessary to specify
el-patch-featuredue to improvements in theel-patchpatching mechanism. - The functions
el-patch-ediff-patch,el-patch-ediff-conflict, andel-patch-unpatchnow take an object name and definition type rather than a patch definition (or function name in the case ofel-patch-unpatch). Interactive usage has not changed.
- As a result of the aforementioned improvements,
el-patch-featureis now a deprecated no-op.
el-patch-splicepreviously acted the same asel-patch-wrap. Now it functions correctly.- The patch definition macros now have their docstrings colored
correctly by the syntax highlighter (by specifying
(declare (doc-string N))). .dir-locals.elis now ignored when validating patches (#2).
- Public API functions:
- Functions for defining patches:
el-patch-defunel-patch-defmacroel-patch-defsubst
- Patch directives:
el-patch-addel-patch-removeel-patch-swapel-patch-wrapel-patch-spliceel-patch-letel-patch-literalel-patch-feature
- Functions for validating patches:
el-patch-validateel-patch-validate-all
- Functions for viewing patches:
el-patch-ediff-patchel-patch-ediff-conflict
- Functions for removing patches:
el-patch-unpatch
- Functions for defining patches: