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.
