| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It appears that having an outdated compat-macs.el loaded can cause
issues when updating between versions with new macros.
|
|
This is done to avoid hidden overlong documentation strings without
folding the first line of the documentation string.
In addition to that, references to the Compat manual are inserted if
possible.
|
|
It appears that having an outdated compat-macs.el loaded can cause
issues when updating between versions with new macros.
|
|
This is a further simplification that avoids difficult edge cases.
Among other things this also satisfied Flymake, that copies and
renames files to a temporary directory, breaking the version inference
process.
|
|
|
|
To avoid the issue like having to find the source of the other files
in the project during byte compilation, we will stop embedding (or
"entwining") the compiled results of compat-*.el into compat.elc.
While this may make loading slightly slower -- in my own tests it was
unnoticeable -- it makes loading Compat a lot easier to manage and
decreases the risk of running into peculiar edge cases, as documented
here[0].
To accommodate for Compat's unusual approach, we still need to do
something unusual, namely rebind the `features' variable, that is used
by `require' to check if a feature is already bound or not. This is
done so that while loading compat-NM.el, the bound version of
`features' is updated but the updated version is reverted back as soon
as the scope of the let-block is left. This allows `compat-NM' to be
loaded again later on, without `compat--inhibit-prefixed' being bound,
as is the case in compat.el. This variable, if bound, suppresses the
evaluation of prefixed definitions, as had previously been done by the
generator function `compat--generate-minimal-no-prefix'.
Another marginal advantage of this approach is that if someone loads
`compat-NM' before `compat' (for whatever reason), `compat-NM' will
not be reloaded, as it is represented in both the actual as well as
the copied value of `features'.
[0] https://todo.sr.ht/~pkal/compat/4#event-180270
|
|
This reverts commit 0c4af13dde7eb9980b636eae42954a9dfea31ba9.
|
|
To avoid the issue like having to find the source of the other files
in the project during byte compilation, we will stop embedding (or
"entwining") the compiled results of compat-*.el into compat.elc.
While this may make loading slightly slower -- in my own tests it was
unnoticeable -- it makes loading Compat a lot easier to manage and
decreases the risk of running into peculiar edge cases, as documented
here[0].
To accommodate for Compat's unusual approach, we still need to do
something unusual, namely rebind the `features' variable, that is used
by `require' to check if a feature is already bound or not. This is
done so that while loading compat-NM.el, the bound version of
`features' is updated but the updated version is reverted back as soon
as the scope of the let-block is left. This allows `compat-NM' to be
loaded again later on, without `compat--inhibit-prefixed' being bound,
as is the case in compat.el. This variable, if bound, suppresses the
evaluation of prefixed definitions, as had previously been done by the
generator function `compat--generate-minimal-no-prefix'.
Another marginal advantage of this approach is that if someone loads
`compat-NM' before `compat' (for whatever reason), `compat-NM' will
not be reloaded, as it is represented in both the actual as well as
the copied value of `features'.
[0] https://todo.sr.ht/~pkal/compat/4#event-180270
|
|
`compat-entwine' is called in two and only three distinct situations.
1. When "compat.el" is being loaded without having been compiled
before. This can happen while a third-party library is being
compiled, which requires `compat'.
2. When "compat.el" is being evaluated, such as when using
`eval-buffer'.
3. When "compat.el" is being compiled.
In all cases we need to detect where "compat.el" is located, because
that also tells us where the "compat-XY.el" libraries are located and
`compat-entwine' needs to read the contents of those files. To detect
the location of "compat.el" we consult various variables, which we
expect to either be nil or "/path/to/compat.el". We didn't use the
correct variables.
Some time ago Stefan added a call to `macro-file-name' to the front
of that search, which fixes the search for Emacs 28.1. Older Emacs
releases lack that function, so for those we still ended up consulting
the wrong variables. To fix that use `current-load-list' directly,
treating it the same way as `macro-file-name' does.
If that gives us a non-nil value, then we are dealing with one of the
first two cases and we are done. Otherwise we are dealing with the
third case and `byte-compile-current-file' gives us the correct value.
One of these sources is always non-nil, so drop the variables we used
to fall back to.
Then we pass the version from `compat-entwine' to the
`compat--generate-function' function by binding the new variable
`compat--entwine-version'. Previously this was done by binding
`byte-compile-current-file`. The caller then had to extract the
version from the name of that file.
Binding `byte-compile-current-file` was also part of the bug that
prevented compilation of a third-party library, which depends on
"compat-XY.el", when compat's libraries have not been compiled yet.
To fix that we have to change the order of the possible sources of the
version string in `compat--generate-function' functions. As before we
use the version explicitly specified for the function being processed,
if any. Then we use value of the new `compat--entwine-version'
variable, if that is bound and non-nil, i.e., if the binding from
`compat-entwine' is in effect.
Previously we would have tried `byte-compile-current-file' at this
point instead, but while that might be non-nil because we used to bind
it in `compat--generate-function', it could also be non-nil because an
arbitrary third-party library is being compiled.
That is a problem if that third-party library depends on
"compat-XY.el" and the latter hasn't been compiled before: The
`compat--generate-function' function is called directly in that case,
without the binding from `compat-entwine' in effect. We need
`byte-compile-current-file' to be some "compat-XY.el" library; not
some arbitrary third-party library.
Then we try `current-load-list' like in `compat-entwine', which here
is some "compat-XY.el" library when some third-party library is being
compiled and that requires that "compat-XY.el" library.
Finally, if we could not determine a version any other way, then we
know that some "compat-XY.el" library is being compiled. In that
case, and only then, we can get the version string from
`byte-compile-current-file'.
|
|
|
|
This avoids confusion when someone is tracking an older development
release, so that compat does not assume all the functionality that was
part of the final release was already available. Instead on a XY.0.Z
release, every definition is checked for availability, just like with
any previous release.
Thanks to Jacek Złydach for bringing the issue to my attention:
https://lists.sr.ht/~pkal/compat-devel/%3Cf8635d7d-e233-448f-b325-9e850363241c%40www.fastmail.com%3E
|
|
|
|
|
|
Since :cond cannot be combined with :prefix, the previous check was
meaningless. What actually should be expressed is that a
compatibility function should only then do the same thing, if we know
by the indicated version that the actual function implements the right
behaviour.
|
|
|
|
As a prefixed function should always be defined (even if the real
function exists and works), using conditions that might result in the
function not being included is contradictory and should be avoided.
|
|
Instead of ignoring the entire compat-deftest block if the
compat-version/-min-version and -max-version properties indicates that
a function shouldn't be tested before or after a specific version.
This restores and improves on the behaviour of before 5514de45.
|
|
Since renaming the file names from XY.Z to XY, the regular expression
that inferred the version didn't do their job.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The plan here is that by default, no prefixed compatibility functions
are loaded, as compat.el byte-compiles minimal definitions, but if a
package or library requires a prefixed function, it can require a
specific component of compat, loading all functions.
|
|
|
|
As it is possible for multiple compat definitions to be given for the
same function, the important thing is not to prevent this, but to
ensure that the conditions prevent both to be applied.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous `compat-generate-common' (now `compat--generate-verbose')
generated a lot of code that was not relevant for 99% of most users,
and can be stripped away, reducing the size of the resulting program
and increasing the speed at which compat is loaded. These factors are
worth optimising and investing complexity into, as compat autoloads
itself and therefore shouldn't burden the user unnecessarily.
|
|
If the ELPA package nadvice has been installed, we can make use of
that instead of our own ersatz-system.
|
|
|
|
Thanks to Stefan Monnier for pointing this out.
|
|
This is a voluntary library a developer might load to have notes
inserted into help buffers of functions that might differ from their
intuitive or expected behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
As currently the only feature that depends on the require advice is
subr-x, and that specifically on version 24.x, we can avoid advising
require in all other cases.
Thank you to Stefan Monnier for pointing this out.
|
|
Previously the advice check inserted a redundant nil at the beginning
of every function or macro definition. This prevented defun/defmacro
from parsing any declare hints.
|
|
|
|
|
|
|
