| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
As mentioned in NEWS.27:
** 'file-name-absolute-p' no longer considers "~foo" to be an absolute
file name if there is no user named "foo".
|
|
|
|
This reverts commit fe923d8ef905dfdc1ca2a78147f5a7d28426d093.
|
|
Texinfo adds these anyway, so there is no need to mention it in the
link name.
|
|
|
|
|
|
|
|
As the default behaviour is just to load missing (unprefixed)
definitions, which are all compiled away if NM ≤ emacs-major-version,
there should be no functional difference. The advantage is that fewer
files have to be opened, parsed and loaded.
Suggested by Daniel Mendler in this thread:
https://lists.sr.ht/~pkal/compat-devel/%3C87cze74icg.fsf_-_%40posteo.net%3E
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It appears that even this is too risky, and can cause issues recursive
loading (from what I understand loading the non-byte compiled
jka-compr.el causes this issue). Instead we will check if
`compat-testing' is bound and true, in which case we explicitly load
the .el file, and otherwise keep the file without a specific suffix.
|
|
This is even simpler and less risky than copying `features' as it
alleviates the risk of confusing the loading procedure.
|
|
This is necessary to avoid loading potentially byte-compiled files
using a generator function other than `compat--generate-verbose' (that
is necessary for testing, to ensure all the necessary meta-data and a
backup definition is provided).
|
|
That way we can avoid loading a feature in case it has already been
loaded previously (and would be contained in the copied value of
`feature'), which should result in a marginal speed improvement.
|
|
Thanks to Stefan Monnier for the tip.
|
|
|
|
|
|
|
|
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.
|
|
This could have been written in a single line, but that would have
resulted in a long line in the long time.
|
|
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
|
|
|
|
|
|
Thanks to Stefan Monnier for noticing
|
|
|
|
This expanded the declare-function forms that in turn caused byte
compilation issues if certain functions were not available, even if
this was to be expected.
|
|
|
|
|
|
In order for `compat--entwine-version' to be passed on to the macro
generator functions, we cannot just bind the variable within the macro
and forget about it. Generating a let binding instead of a
`progn'-block is likewise insufficient, as this would only affect the
evaluation, not the macro-expansion. It is therefore necessary to
expand all macros (or at least all macros using
`compat--generate-function', which for our intent is almost every
case) while binding `compat--entwine-version', so that the binding is
preserved.
If this is not done, the version cannot be determined when loading
compat.el (the main file). To my understanding this is not fatal,
because all this affects is that compat.elc cannot be generated, so
the slower compat.el has to be loaded.
|
|
|
|
|
|
|
|
`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'.
|
|
|
|
|
|
* compat-26.el (func-arity, assoc): Silence the compiler about
fancy quotes with Emacs 29.
|
