On 01/10/2014 11:24 AM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
As a suggestion, the documentation should also be upgraded to reflect the change to github and any other new features that are added.
Yes. I reworked the setup instructions (and reworked the `slime-setup' mechanism slightly), have a look at the new README in the github home page and try it out.
I was referring to the manual that is in the slime/doc folder, which still contains all the CVS instructions for downloading slime. I keep the slime manual handy for reference. Sorry I didn't make myself clear in my last message.
Oh, you're right, that needs updating too.
We'll make updating the texinfo manual a prerequisite for the next release. I'm afraid we won't be able to update your existing printed copy though :-)
Still, the trunk might always contain some instability, in those cases do fallback to the last tag and report those bugs in the issue tracker. We'll try to sort out a release strategy as soon as possible.
I did notice some problems in the master branch, so I checked out SLIME_2 and used that.
Care to describe them? I'd be very insterested.
I get several messages when I start slime after checking out the master branch.
Connecting to Swank on port 34085.. error in process filter: slime-for-each-presentation-in-region: Invalid function: (handle-presentation (presentation point) (multiple-value-bind (start end whole-p) (slime-presentation-bounds point presentation object) (funcall function presentation start end whole-p))) error in process filter: Invalid function: (handle-presentation (presentation point) (multiple-value-bind (start end whole-p) (slime-presentation-bounds point presentation object) (funcall function presentation start end whole-p)))
That was not the case yesterday, but this morning I downloaded slime again thinking that the manual may have been updated and now I get the messages when I start slime. I also get similar messages when I use "repl>clear buffer" menu item.
João
Paul Bowyer pbowyer@olynet.com writes:
As a suggestion, the documentation should also be upgraded to reflect the change
I've just pushed an update to the manual that reflects the new infrastructure changes, updates installation recipes, et-cetera. I added a section "Emacs 23 gotchas" and a section about on-the-fly loading of contribs that describes the pitfalls of doing so.
Have a look if it's up to the existing standards (which are pretty high imo).
João
On Sat, Jan 11 2014, João Távora wrote:
[...]
I've just pushed an update to the manual that reflects the new infrastructure changes, updates installation recipes, et-cetera. I added a section "Emacs 23 gotchas" and a section about on-the-fly loading of contribs that describes the pitfalls of doing so.
Have a look if it's up to the existing standards (which are pretty high imo).
It seems that the new autoload instructions don't add anything to lisp-mode-hook. Only after M-x slime is invoked the first time which autoloads slime, then lisp-mode-hook is modified as a side effect. This modify lisp-mode-hook as side effect of loading, looks like bad style to me.
The "on-the-fly loading" is traditionally done with M-x load-library <contrib> followed by M-x slime-enable-contrib <contrib>
Also using M-x slime-disable-contrib is probably better than callint the misnamed slime-<contrib>-unload directly.
Helmut
Helmut Eller eller.helmut@gmail.com writes:
On Sat, Jan 11 2014, João Távora wrote:
Have a look if it's up to the existing standards (which are pretty high imo).
It seems that the new autoload instructions don't add anything to lisp-mode-hook.
You're right. It should be there. I misunderstood this bit.
Notice that in the future the autoload file should be autogenerated from autoload cookies so that addition will be in *both* files at the top-level and be executed twice: once when loading the autoloads file and once when the autoload is triggered.
This is what all major modes do in Emacs do for "auto-mode-alist" and is no problem if `add-to-list' or `add-hook' are used.
The "on-the-fly loading" is traditionally done with M-x load-library <contrib> followed by M-x slime-enable-contrib <contrib>
Also using M-x slime-disable-contrib is probably better than callint the misnamed slime-<contrib>-unload directly.
I'll make both these changes.
João
Paul Bowyer pbowyer@olynet.com writes:
Care to describe them? I'd be very insterested.
I get several messages when I start slime after checking out the master branch.
Connecting to Swank on port 34085.. error in process filter: slime-for-each-presentation-in-region: Invalid function: (handle-presentation (presentation point)
Thanks, I reproduced in emacs 23 and fixed this. Can you confirm?
Here's the commit message that explains it, if you're interested. It's an artifact of the imperfect migration of the CL lib from dynamic-binding to lexical-binding, even with cl-lib.el.
Use cl-labels instead of cl-flet, safe for emacs 23.
The cl-flet alias doesn't exist in cl-lib-0.3. Making it is a big mistake. Better use cl-labels with non-lexical-binding behaviour in emacs-23 (though a warning is printed)
It only affected the slime-presentations contrib. We don't have the CI system setup for contribs yet, unfortunately, with would easily have caught this bug and I wouldn't have commited.
João
On 01/10/2014 03:26 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
Care to describe them? I'd be very insterested.
I get several messages when I start slime after checking out the master branch.
Connecting to Swank on port 34085.. error in process filter: slime-for-each-presentation-in-region: Invalid function: (handle-presentation (presentation point)
Thanks, I reproduced in emacs 23 and fixed this. Can you confirm?
This morning, I downloaded the latest slime from github. I did the "make ensure_ert", "make clean" and "make compile" thing, but I did not notice cl-lib.el before doing "make compile". Since it seemed to be missing, I started slime in emacs and it seemed to start OK. I exited slime and emacs then I took another look at the slime folder and this time I noticed cl-lib.el was present, so I loaded it in my .emacs file and restarted slime in emacs and again it seemed to start OK.
Is it now OK to run slime without loading cl-lib.el or is it still necessary to load it? I could not determine a difference when starting slime without and with it.
I also took a quick look at the changes in the slime manual and notice one small typo "git diff HEAD origin/master ChangeLo" in "2.2.2 Git incantations" but otherwise it seemed OK in my cursory examination.
I experimented some more by starting slime with/without loading cl-lib.el and I noticed some more messages that were not dependent on the loading of cl-lib.el.
error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only
The messages showed whether or not I loaded cl-lib.el, but I didn't notice any ill effects when I used some of the slime menu commands.
Here's the commit message that explains it, if you're interested. It's an artifact of the imperfect migration of the CL lib from dynamic-binding to lexical-binding, even with cl-lib.el.
Use cl-labels instead of cl-flet, safe for emacs 23. The cl-flet alias doesn't exist in cl-lib-0.3. Making it is a big mistake. Better use cl-labels with non-lexical-binding behaviour in emacs-23 (though a warning is printed)It only affected the slime-presentations contrib. We don't have the CI system setup for contribs yet, unfortunately, with would easily have caught this bug and I wouldn't have commited.
João
Paul Bowyer pbowyer@olynet.com writes:
On 01/10/2014 03:26 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
Care to describe them? I'd be very insterested.
This morning, I downloaded the latest slime from github. I did the "make ensure_ert", "make clean" and "make compile" thing, but I did not notice cl-lib.el before doing "make compile". Since it seemed to ...
"ensure_ert" doesn't pull in cl-lib, it pulls in ert. "ensure_cl_lib" does pulls in cl-lib.el and the "compile" target depends on "ensure_cl_lib", which I think explains your observations.
Anyway I'm starting to think we shold bundle cl-lib.el (and ert.el as well for good measure). Travis CI fails lately because the site it downlaods cl-lib.el from is down.
The only thing that bugs me is the growing list of "bundled" third party files at to plevel. Helmut, can we move these to a new "vendor" dir? Maybe not hyperspec.el, unless we:
* add "vendor" directly to the load-path as well.
* we complicate the non-autoload installation recipe. The autoload file can set the hyperspec autoload to "vendor/hyperspec".
I prefer the second.
Is it now OK to run slime without loading cl-lib.el or is it still necessary to load it? I could not determine a difference when starting slime without and with it.
On Emacs 23 it has to either be loaded or be in your load-path. Emacs's `require' takes care of the rest.
I also took a quick look at the changes in the slime manual and notice one small typo "git diff HEAD origin/master ChangeLo" in "2.2.2 Git incantations" but otherwise it seemed OK in my cursory examination.
OK.
I experimented some more by starting slime with/without loading cl-lib.el and I noticed some more messages that were not dependent on the loading of cl-lib.el.
error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only
The messages showed whether or not I loaded cl-lib.el, but I didn't notice any ill effects when I used some of the slime menu commands.
Funny. `slime-repl-emit' doesn't have any advice set. Maybe you do so in your ~/.emacs? Can you reproduce this with emacs -Q and paste the reproduction recipe here?
João
On Sat, Jan 11 2014, João Távora wrote:
The only thing that bugs me is the growing list of "bundled" third party files at to plevel. Helmut, can we move these to a new "vendor" dir? Maybe not hyperspec.el, unless we:
add "vendor" directly to the load-path as well.
we complicate the non-autoload installation recipe. The autoload file can set the hyperspec autoload to "vendor/hyperspec".
I prefer the second.
I would call it "lib" and also wouldn't add it to the load-path.
If you're breaking everybody's .emacs then you can just as well drop the non-autoload receipe. It's primarily there because that's the way SLIME was loaded since the very beginning.
Helmut
Helmut Eller eller.helmut@gmail.com writes:
On Sat, Jan 11 2014, João Távora wrote:
I would call it "lib" and also wouldn't add it to the load-path.
OK. I'll move nregex.lisp, hyperspec.el and the new cl-lib.el and ert-el into that directory and update the "Emacs 23 gotchas" section.
What about these ideas:
* With some work on swank-loader's *SYSDEP-FILES*, we could move metering.lisp, xref.lisp and the lisp backends.
* In that case we could organize lib into "backends" and "etc".
* While we're there, a "test" top level dir could host slime-tests.el, and the new files containing just contrib test as well (so loading them doesn't trigger the ERT warning).
If you're breaking everybody's .emacs then you can just as well drop the non-autoload receipe.
I don't understand. AFAICT, the non-autoload recipe was not broken, and I see no no reason to break it. In any case I'm _trying_ to do just the opposite: not break user's ~/.emacs files.
As you reported the "visit lisp files early" case *was* indeed broken, but I warned beforehand about possible instability. Anyway I have now fixed it. I added new tests "readme-recipe" and "readme-recipe-autoload-on-lisp-visit". If you can think of more cases do tell me or add them.
But I agree with should make the autoload recipe the main recommended recipe. Autoloads is how package.el and el-get are going to set things up when we package SLIME for them and how MELPA sets things up when it builds automatically.
Doing that:
* We can change `slime-setup' to not do the add-hook step.
* We can deprecate slime-enable-contrib and slime-disable-contrib. I had agreed before on mentioning them in the doc (they aren't now), but I've changed my mind. They promise functionality they can't really keep, don't you think? No emacs package I know promises to "disable" itself. There are "modes" though and SLIME uses plenty of them which *do* keep their promises.
* If we do the above step we might, someday in the future, make `slime-setup' essentially a no-op. `require' and autoloads are the normal Emacs way of activating functionality and I think there is (in recent GNU Emacsen) enough functionality to make `define-slime-contrib' obsolete.
So, in the future, (mapc #'require slime-contribs) might be all that is required and it's much more idiomatic elisp. And the existing ~/.emacs needn't be broken.
João
On Sun, Jan 12 2014, João Távora wrote:
What about these ideas:
With some work on swank-loader's *SYSDEP-FILES*, we could move metering.lisp, xref.lisp and the lisp backends.
In that case we could organize lib into "backends" and "etc".
While we're there, a "test" top level dir could host slime-tests.el, and the new files containing just contrib test as well (so loading them doesn't trigger the ERT warning).
I'm not very enthusiastic about that. The technical reason to do it isn't so obvious. There may aesthetic reasons, but those are, as always, debatable.
If you're breaking everybody's .emacs then you can just as well drop the non-autoload receipe.
I don't understand. AFAICT, the non-autoload recipe was not broken, and I see no no reason to break it. In any case I'm _trying_ to do just the opposite: not break user's ~/.emacs files.
Well, you said that changes to the non-autoload recipe may be necessary. If you do that then you could also drop it entirely.
[...]
But I agree with should make the autoload recipe the main recommended recipe. Autoloads is how package.el and el-get are going to set things up when we package SLIME for them and how MELPA sets things up when it builds automatically.
Doing that:
We can change `slime-setup' to not do the add-hook step.
We can deprecate slime-enable-contrib and slime-disable-contrib. I had agreed before on mentioning them in the doc (they aren't now), but I've changed my mind. They promise functionality they can't really keep, don't you think? No emacs package I know promises to "disable" itself. There are "modes" though and SLIME uses plenty of them which *do* keep their promises.
Not sure what slime-enable-contrib promises. It practice, it adds various hooks and slime-disable-contrib removes those hooks again; that's certainly possible. It would also be possible to enable resp. disable modes with these commands, tho, perhaps not very useful. Binding/unbinding keys may be possible but it's obviously tricky.
I don't think these commands need to be documented in the manual, but they are useful for debugging.
- If we do the above step we might, someday in the future, make `slime-setup' essentially a no-op. `require' and autoloads are the normal Emacs way of activating functionality and I think there is (in recent GNU Emacsen) enough functionality to make `define-slime-contrib' obsolete.
So, in the future, (mapc #'require slime-contribs) might be all that is required and it's much more idiomatic elisp. And the existing ~/.emacs needn't be broken.
Doesn't sound very idiomatic to me. IMO, loading a package and enabling it should be separate steps. The elisp manual seems to agree with me (elisp)Coding Conventions::
* Simply loading a package should not change Emacs's editing behavior. Include a command or commands to enable and disable the feature, or to invoke it.
Helmut
Helmut Eller eller.helmut@gmail.com writes:
I'm not very enthusiastic about that. The technical reason to do it isn't so obvious. There may aesthetic reasons, but those are, as always, debatable.
OK. But I just gave you one such asthetic reason
me> The only thing that bugs me is the growing list of "bundled" third me> party files at top level. Helmut, can we move these to a new me> "vendor" dir?
and apparently won the debate immediately :-) Which files are you more/less enthusiastic about moving around?
If you're breaking everybody's .emacs then you can just as well drop the non-autoload receipe.
I don't understand. AFAICT, the non-autoload recipe was not broken, and I see no no reason to break it. In any case I'm _trying_ to do just the opposite: not break user's ~/.emacs files.
Well, you said that changes to the non-autoload recipe may be necessary. If you do that then you could also drop it entirely.
You misunderstood me when I said "complicate the non-autoload installation recipe". I meant we must complicate our program to do something akin to replacing:
(require 'hyperspec ...)
with
(require 'hyperspec "lib/hyperspec.el")
And that's quite different from "breaking everybody's .emacs", ie. breaking existing instances of that recipe.
Again, that is something I don't want to do.
- We can deprecate slime-enable-contrib and slime-disable-contrib. I had
Not sure what slime-enable-contrib promises.
Precisely my point.
It would also be possible to enable resp. disable modes with these
I don't understand "reps. disable modes", but I agree they aren't very useful. See the end of the mssage for a proposal.
I don't think these commands need to be documented in the manual, but they are useful for debugging.
Perhaps they should be in a "slime-debugging" contrib and not in SLIME? Or in slime-tests? At the least they should be reprefixed "slime--".
Actually a lot of code seems like it would make a good candidate for that contrib/file. For example the curious "urge-recompile" and the manual recompilation of some functions, which I think were made obsolete by "make compile" are more candidates.
So, in the future, (mapc #'require slime-contribs) might be all that is
Doesn't sound very idiomatic to me. IMO, loading a package and enabling it should be separate steps. The elisp manual seems to agree with me (elisp)Coding Conventions::
I think you may be misunderstanding the spirit of the guideline. The key is
...should not change Emacs's editing behaviour
^^^^^^^ It means you shouldn't change stuff like global keybindings or the value of the `fill-column' variable, which makes perfect sense to me.
For example, just by `requiring' python-mode or ruby-mode, files with those extensions will automatically be opened in that mode. Requiring slime-autoloads does the same for lisp files and requiring some contrib files could follow in the same spirit.
But to be clear, I *agree with you*, and my suggestion sucks, or at least was very lacking. Contribs should rather be minor-modes defined by `define-globalized-minor-mode'
So for most of them:
(require 'slime-foo-autoloads) (slime-foo-mode 1) ;; prints a warning if there are more connections ;; besides the current one
slime-repl's mode should be called something like slime-auto-repl-mode, meaning a repl is automatically launched.
But these are suggestions for the future. There are most interesting problems right now.
João
On Sun, Jan 12 2014, João Távora wrote:
Helmut Eller eller.helmut@gmail.com writes:
I'm not very enthusiastic about that. The technical reason to do it isn't so obvious. There may aesthetic reasons, but those are, as always, debatable.
OK. But I just gave you one such asthetic reason
me> The only thing that bugs me is the growing list of "bundled" third me> party files at top level. Helmut, can we move these to a new me> "vendor" dir?
and apparently won the debate immediately :-)
Having cl-lib and ert in the toplevel directory would be problematic because they conflict with the libraries in Emacs 24. That's a technical reason to move them out of the load-path.
Which files are you more/less enthusiastic about moving around?
The testing code is probably the easiest to move.
[...]
I don't think these commands need to be documented in the manual, but they are useful for debugging.
Perhaps they should be in a "slime-debugging" contrib and not in SLIME? Or in slime-tests? At the least they should be reprefixed "slime--".
Actually, it might be good to move everything related to contribs to a contrib. So that SLIME, including slime-autoloads, doesn't need to know that contribs exist.
Actually a lot of code seems like it would make a good candidate for that contrib/file. For example the curious "urge-recompile" and the manual recompilation of some functions, which I think were made obsolete by "make compile" are more candidates.
"urge-recompile" doesn't sound obsolete as long as Emacs loads .elc files that are older than the corresponding .el file.
Helmut
Helmut Eller eller.helmut@gmail.com writes:
OK. But I just gave you one such asthetic reason
me> The only thing that bugs me is the growing list of "bundled" third me> party files at top level. Helmut, can we move these to a new me> "vendor" dir?
and apparently won the debate immediately :-)
Having cl-lib and ert in the toplevel directory would be problematic because they conflict with the libraries in Emacs 24. That's a technical reason to move them out of the load-path.
Fair enough, but the problem still exists even if you move them to lib. It is solved relatively elegantly with this technique, which is what I just pushed.
(eval-and-compile (require 'cl-lib nil t) ;; For emacs 23, look for bundled version (require 'cl-lib "lib/cl-lib"))
In the end if you think this modularization is mostly about asthethics, I can agree. But I argue we should be slightly arty if that brings readability, more developers, and flexibility for current/unseen scenarios.
Anyway, I agree this debate is not really priority, I was just seeing what I could squeeze out of this.
I think the priority is fixing broken stuff and adding robustness. Then refactorings will become almost self-evident.
See the latest commit for the changes that address the latest latest concerns. Mainly two points;
* No more Emacs 23 gotchas.
* There is a new "traditional-recipe" test that complements the autoload case. It launches a separate emacs process with a very bare .emacs and launches slime there.
* I've now enabled the contrib tests in the Travis CI. I had to skip 2 tests, but we went from 184 to 297 tests, which is good, I think.
The contrib tests are tested in separate runs: we now have this in travis:
- LISP_BIN=sbcl EMACS_BIN=emacs make clean check - LISP_BIN=sbcl EMACS_BIN=emacs-snapshot make clean check - LISP_BIN=sbcl EMACS_BIN=emacs make clean check-fancy - LISP_BIN=sbcl EMACS_BIN=emacs-snapshot make clean check-fancy
Luís is working on a big improvement to this, stay tuned...
The testing code is probably the easiest to move.
OK, nice. What's second-easiest? :-)
I don't think these commands need to be documented in the manual, but they are useful for debugging.
Perhaps they should be in a "slime-debugging" contrib and not in SLIME? Or in slime-tests? At the least they should be reprefixed "slime--".
Actually, it might be good to move everything related to contribs to a contrib. So that SLIME, including slime-autoloads, doesn't need to know that contribs exist.
But at least the variable "slime-contribs" and "slime-setup" must be there, I think. Well as long we don't break any existing recipes.
"urge-recompile" doesn't sound obsolete as long as Emacs loads .elc files that are older than the corresponding .el file.
"make compile" checks mtimes. Would you be willing to use something like this in your ~/.emacs instead?
(defadvice slime (before slime-urge-bytecode-recompile activate) (let ((default-directory slime-path)) (unless (zerop (shell-command "make compile 2>&1 | tail -1 | grep '0 files compiled'")) (when (and (file-readable-p "slime.elc") (y-or-n-p "Reload slime.elc?")) (load "slime.elc")))))
Or moving that code to that slime-debugging contrib?
João
On Sun, Jan 12 2014, João Távora wrote:
The testing code is probably the easiest to move.
OK, nice. What's second-easiest? :-)
Then create your "backend" directory. If that finally stops this game.
Actually, it might be good to move everything related to contribs to a contrib. So that SLIME, including slime-autoloads, doesn't need to know that contribs exist.
But at least the variable "slime-contribs" and "slime-setup" must be there, I think. Well as long we don't break any existing recipes.
slime-contribs is new; it wasn't there before.
"urge-recompile" doesn't sound obsolete as long as Emacs loads .elc files that are older than the corresponding .el file.
"make compile" checks mtimes. Would you be willing to use something like this in your ~/.emacs instead?
(defadvice slime (before slime-urge-bytecode-recompile activate) (let ((default-directory slime-path)) (unless (zerop (shell-command "make compile 2>&1 | tail -1 | grep '0 files compiled'")) (when (and (file-readable-p "slime.elc") (y-or-n-p "Reload slime.elc?")) (load "slime.elc")))))
Or moving that code to that slime-debugging contrib?
It's not about me. It's about people who do "git pull" then forget "make compile".
Helmut
In the end if you think this modularization is mostly about asthethics, I can agree. But I argue we should be slightly arty if that brings readability, more developers, and flexibility for current/unseen scenarios.
as most of programming is building stuff on turing complete systems, much more of it is about aesthetics than most people dare to admit.
(although, cognitive psychology can be brought into the picture to objectify *some* of those aesthetics in case of team efforts...)
sorry for an offtopic 0.02,
On 01/11/2014 01:10 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
On 01/10/2014 03:26 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
Care to describe them? I'd be very insterested.
This morning, I downloaded the latest slime from github. I did the "make ensure_ert", "make clean" and "make compile" thing, but I did not notice cl-lib.el before doing "make compile". Since it seemed to ...
"ensure_ert" doesn't pull in cl-lib, it pulls in ert. "ensure_cl_lib" does pulls in cl-lib.el and the "compile" target depends on "ensure_cl_lib", which I think explains your observations.
Anyway I'm starting to think we shold bundle cl-lib.el (and ert.el as well for good measure). Travis CI fails lately because the site it downlaods cl-lib.el from is down.
The only thing that bugs me is the growing list of "bundled" third party files at to plevel. Helmut, can we move these to a new "vendor" dir? Maybe not hyperspec.el, unless we:
add "vendor" directly to the load-path as well.
we complicate the non-autoload installation recipe. The autoload file can set the hyperspec autoload to "vendor/hyperspec".
I prefer the second.
Is it now OK to run slime without loading cl-lib.el or is it still necessary to load it? I could not determine a difference when starting slime without and with it.
On Emacs 23 it has to either be loaded or be in your load-path. Emacs's `require' takes care of the rest.
I also took a quick look at the changes in the slime manual and notice one small typo "git diff HEAD origin/master ChangeLo" in "2.2.2 Git incantations" but otherwise it seemed OK in my cursory examination.
OK.
I experimented some more by starting slime with/without loading cl-lib.el and I noticed some more messages that were not dependent on the loading of cl-lib.el.
error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only
The messages showed whether or not I loaded cl-lib.el, but I didn't notice any ill effects when I used some of the slime menu commands.
Funny. `slime-repl-emit' doesn't have any advice set. Maybe you do so in your ~/.emacs? Can you reproduce this with emacs -Q and paste the reproduction recipe here?
I tried emacs -Q and there were no error messages. They only occur after I start slime using M-x slime, which I was unable to do after opening emacs with -Q. It must be something related to my .emacs file. I'll try to track it down.
João
On 01/11/2014 01:10 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
On 01/10/2014 03:26 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
Care to describe them? I'd be very insterested.
This morning, I downloaded the latest slime from github. I did the "make ensure_ert", "make clean" and "make compile" thing, but I did not notice cl-lib.el before doing "make compile". Since it seemed to ...
"ensure_ert" doesn't pull in cl-lib, it pulls in ert. "ensure_cl_lib" does pulls in cl-lib.el and the "compile" target depends on "ensure_cl_lib", which I think explains your observations.
Anyway I'm starting to think we shold bundle cl-lib.el (and ert.el as well for good measure). Travis CI fails lately because the site it downlaods cl-lib.el from is down.
The only thing that bugs me is the growing list of "bundled" third party files at to plevel. Helmut, can we move these to a new "vendor" dir? Maybe not hyperspec.el, unless we:
add "vendor" directly to the load-path as well.
we complicate the non-autoload installation recipe. The autoload file can set the hyperspec autoload to "vendor/hyperspec".
I prefer the second.
Is it now OK to run slime without loading cl-lib.el or is it still necessary to load it? I could not determine a difference when starting slime without and with it.
On Emacs 23 it has to either be loaded or be in your load-path. Emacs's `require' takes care of the rest.
I also took a quick look at the changes in the slime manual and notice one small typo "git diff HEAD origin/master ChangeLo" in "2.2.2 Git incantations" but otherwise it seemed OK in my cursory examination.
OK.
I experimented some more by starting slime with/without loading cl-lib.el and I noticed some more messages that were not dependent on the loading of cl-lib.el.
error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only
The messages showed whether or not I loaded cl-lib.el, but I didn't notice any ill effects when I used some of the slime menu commands.
Funny. `slime-repl-emit' doesn't have any advice set. Maybe you do so in your ~/.emacs? Can you reproduce this with emacs -Q and paste the reproduction recipe here?
I wrote this earlier...
I tried emacs -Q and there were no error messages. They only occur after I start slime using M-x slime, which I was unable to do after opening emacs with -Q. It must be something related to my .emacs file. I'll try to track it down.
More on the subject... It turns out that the problem is caused by my use of log4cl that I was loading in my .emacs file.
(load "~/quicklisp/log4slime-setup.el") (global-log4slime-mode 1) ;;This generates a compiler warning (but not the error messages I described)
It doesn't matter where I place these two entries in my .emacs (as long as I can get it to load), they generate the errors I described.
Paul Bowyer
João
-
Attila Lendvai -
Helmut Eller -
joaotavora＠gmail.com -
Paul Bowyer