In "el-get-start-process-list", increase "max-specpdl-size" by 100 for
each command in in the list. This allows
"el-get-start-process-list" (but not other functions) to recurse
indefinitely.
This is needed for the emacs-goodies-el recipe, which generates many
build commands and will overflow the default of max-specpdl-size
during the build.
This prevents Emacs from inserting "..." in place of very deep or long
data structures, which could corrupt the status file in some cases.
This is done by defining a wrapper function "el-get-print-to-string",
which el-get should use for all "critical" stringification tasks.
As noted in #689.
It encapsulates the following common pattern, used several times in
el-get to allow recipe properties to override defaults if present:
(if (plist-member plist prop)
(plist-get plist prop)
default)
The new implementation no longer depends on the :type property of the
package, meaning that you can actually `el-get-remove' a package whose type
changed in its recipe.
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
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"
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.