That cleans up the code and allow not to depend on the :reload property, and
cater with some edge cases like features currently loaded but no longer
present in the updated package.
Conflicts:
el-get.el
Notify functions can sometimes fail (due to dbus errors and such), and
this should not cause el-get to halt, because notification is arguably
non-essential. If the chosen notification method fails, "message" is
used instead.
The previous patches are changing the behavior in a user visible way for
recipes. Update user documentation to reflect the change and upgrade the
minor version number to be able to track this.
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"
Use it like this:
(url-retrieve
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
(lambda (s)
(let ((el-get-install-branch "3.stable"))
(end-of-buffer)
(eval-print-last-sexp))))
This variable takes precedence over "el-get-master-branch", and must
be set to a string.
Documentation for this needs to be added to the readme.
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.
I haven't tested this at all, but assuming that the :build property of
a recipe gets passed through el-get-build and subsequently
el-get-start-process-list, the recipe itself should never use
`shell-quote-argument`.
Same reason as in 11ef806a. The result of this function is passed to
`el-get-start-process-list` with a `:shell t` option, which results in
shell-quoting. So doing it here is redundant and potentially harmful.
Before, the newly-installed el-get package was loaded while
`el-get-default-process-sync` and `el-get-post-install` were
let-bound, which caused their corresponding `defvar` statements to be
ignored, which resulted in a non-functional el-get unless one manually
re-loaded el-get or restarted emacs.
