Since Emacs 27 the package cl is deprecated, the replacement is
cl-lib, which is available since Emacs 24.3.
This patch replaces cl by cl-lib and drops support for Emacs versions
less than 24.3. Dropping older Emacsen is required, because cl-lib is
a builtin starting from version 24.3 and doesn't need an extra package
from ELPA.
Testcases for past issues still contain cl. Most of them seem to be
broken and need further investigation.
This patch is tested with test/run-ert.sh, which outputs:
Ran 10 tests, 10 results as expected, 0 unexpected (2021-01-30 13:24:54+0100, 0.672122 sec)
1 expected failures
and manually by daily usage for a month now.
It knows argument to eval-after-load is code, and that #' implies
existence of a function.
Some of the package.el functions have changed, but that will be dealt
with separately.
Move more variables to el-get-custom.el, add requires or
declare-functions as needed.
There were a few places that appeared to be actual bugs: wrong or
missing variable names.
The problem was that the "sync" symbol was inside a backquote and was
not comma-prefixed, so the ":sync" property was getting set literall
to the symbol "'sync" instead of its value. Obviously, "'sync" is a
true value, so the commands were all run synchronously.
Fixes#307.
Fixes#385.
Build commands are supposed to be either strings or lists of strings.
But the code for deciding whether to eval the :build property only
checks for a string, not a list. This commit fixes this, so that a
build property whose commands are all lists of strings should no
longer cause an error. Evaluation of the :build property now only
happens when the car is a symbol, since that is the only time that
evaluation would not result in an error.
Also in this commit:
* Ensure build commands are all strings or lists of strings and raise
an error otherwise. The check happens after flattening, so nested
lists of strings should also pass.
* A few syntax fixes
* Add a function "el-get-list-of-strings-p"
El-get-build allows a command to be specified as a single string. It
will split that string on whitespace into a list of strings, and each
element of that list will eventually be shell-quoted (by
`el-get-start-process-list`). This is wrong behavior that can easily
cause an innocent command to be over-escaped or split into too many
arguments, or both. For example, consider a build process that
involves running the following command:
make SOME_OPTION="this is the option value"
Written as a string in Elisp, that would be:
"make SOME_OPTION=\"this is the option value\""
After splitting on whitespace and then shell-quoting and then passing
the result to the shell, the above command is equivalent to running
the following at the shell:
"make" "SOME_OPTION=\"this" "is" "the" "option" "value\""
See the problem? What was once a single argument is now five, and the
quotation marks have been inappropriately quoted. For this reason, I
think auto-whitespace splitting should probably be deprecated. The
command should either be a single string, which would be interpreted
as a command to be run with no arguments, or a list of strings, like
this:
'("make" "SOME_OPTION=\"this is the option value\"")
The `el-get-install-or-init-info` composed a command as a single
pre-quoted string using `concat` and `shell-quote-argument`. It is
better to make the command a list of unquoted arguments, which is what
this commit does.
This includes teaching methods that they now work with a symbolp PACKAGE,
some more cleaning up, and some load-path adjustments now that a part of the
code is in a subdirectory (methods).
Also include some of the tests used to convince oneself that the refactoring
didn't break any and all use cases for el-get, with some rough documentation
about how to use them.