Moving to GitHub and cl-lib
As you may have heard, we're moving the SLIME repository to GitHub. The new location is: https://github.com/slime/slime The bug tracker will also be moved from Lunchpad to GitHub. João Távora has already done some work in the new repository. In particular SLIME now requires the cl-lib library. As you probably know, the Emacs maintaners have declared the cl library obsolete, and encourage everybody to use the new names. What used to be "find" from the cl library is now called "cl-find" and in the cl-lib library. If you're using Emacs 23 then you need to install cl-lib manually, i.e. grab the .el file from http://elpa.gnu.org/packages/cl-lib.html and drop it somewhere into Emacs' load-path. Is that too much hassle? Should we include scripts to automate this or perhaps include cl-lib-3.0.el in our repo? cl-lib may or may not work with XEmacs. This poses the questions: are there many XEmacs users left? Would you be very unhappy if we drop XEmacs support? Or are you a "I'd be happier with XEmacs but GNU Emacs is also OK" kind of person? Helmut
"Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:
Helmut> cl-lib may or may not work with XEmacs. This poses the questions: are Helmut> there many XEmacs users left? Would you be very unhappy if we drop Probably just me. Helmut> XEmacs support? Or are you a "I'd be happier with XEmacs but GNU Emacs Unhappy? Yes. Very unhappy? Probably not. Helmut> is also OK" kind of person? I haven't looked to see what cl-lib is, but if it's just a bunch of functions to give elisp-equivalents of CL functions, then that should be doable. Besides, slime has already stopped working on XEmacs for a few things like M-. The fucntion called-interactively-p doesn't exist on XEmacs. I haven't had a chance to dig further into it. Ray
Raymond Toy <toy.raymond@gmail.com> writes:
like M-. The fucntion called-interactively-p doesn't exist on XEmacs. I haven't had a chance to dig further into it.
The good news is that that particular call to `called-interactively-p' is now gone (it's a mispractice in Emacs, too), the bad news is that recent cleanup might have introduced other cases where xemacs no longer behaves as emacs.
"João" == João Távora <joaotavora@gmail.com> writes:
João> Raymond Toy <toy.raymond@gmail.com> writes: >> like M-. The fucntion called-interactively-p doesn't exist on XEmacs. >> I haven't had a chance to dig further into it. João> The good news is that that particular call to `called-interactively-p' João> is now gone (it's a mispractice in Emacs, too), the bad news is that João> recent cleanup might have introduced other cases where xemacs no longer João> behaves as emacs. Thanks for the good (and bad) news. I'll try the git version soon; I normally just use guicklisp to get slime. Ray
"Raymond" == Raymond Toy <toy.raymond@gmail.com> writes:
"João" == João Távora <joaotavora@gmail.com> writes: Raymond> João> Raymond Toy <toy.raymond@gmail.com> writes: >>> like M-. The fucntion called-interactively-p doesn't exist on XEmacs. >>> I haven't had a chance to dig further into it.
Raymond> João> The good news is that that particular call to `called-interactively-p' Raymond> João> is now gone (it's a mispractice in Emacs, too), the bad news is that Raymond> João> recent cleanup might have introduced other cases where xemacs no longer Raymond> João> behaves as emacs. Raymond> Thanks for the good (and bad) news. Raymond> I'll try the git version soon; I normally just use guicklisp to get Raymond> slime. FWIW, I tried the latest git version. I grabbed a copy of cl-lib.el and hacked a few files so that (require 'ert) and (require 'slime-tests) aren't done, and defined a dummy def-slime-test macro. The result works just fine on xemacs, with just a few minutes of testing, though. M-. works again too, so that is nice. Typing #+ usually causes xemacs to hang. C-g aborts that and then I can finish typing the rest of #+.... I think it's a fontification issue or something like that. Anyway, I've learned to live with that, since that's been happening for a long while now, since I don't type reader conditionals too often. Ray
Raymond Toy <toy.raymond@gmail.com> writes:
The result works just fine on xemacs, with just a few minutes of testing, though. M-. works again too, so that is nice.
Quite amazing that we actually managed to improve the xemacs experience by removing support for it... But I'm afraid things might get worse sooner rather than later. We'll see: keep using slime! João
"João" == João Távora <joaotavora@gmail.com> writes:
João> Raymond Toy <toy.raymond@gmail.com> writes: >> The result works just fine on xemacs, with just a few minutes of >> testing, though. M-. works again too, so that is nice. João> Quite amazing that we actually managed to improve the xemacs experience João> by removing support for it... Heh. João> But I'm afraid things might get worse sooner rather than later. We'll João> see: keep using slime! I will. Would you accept a patch to fix the test issues I've uncovered? My current hack is too gross, but I can try to come up with something cleaner. Otherwise, continuing to use git slime will be a pain to maintain. I normally only update slime when quicklisp does. Ray
On Tue, Jan 07 2014, Raymond Toy wrote:
João> see: keep using slime!
I will. Would you accept a patch to fix the test issues I've uncovered? My current hack is too gross, but I can try to come up with something cleaner. Otherwise, continuing to use git slime will be a pain to maintain. I normally only update slime when quicklisp does.
I also vote for dropping XEmacs compatibility. Ray, you are the CMUCL maintainer and I certainly would like to provide you a working SLIME for that. But apparently you are the last XEmacs user. That's a very small minority. Overall, I think it's wiser and fairer to spend our time on things other than XEmacs. Helmut
"Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:
Helmut> On Tue, Jan 07 2014, Raymond Toy wrote: >> João> see: keep using slime! >> >> I will. Would you accept a patch to fix the test issues I've >> uncovered? My current hack is too gross, but I can try to come up >> with something cleaner. Otherwise, continuing to use git slime will >> be a pain to maintain. I normally only update slime when quicklisp >> does. Helmut> I also vote for dropping XEmacs compatibility. Helmut> Ray, you are the CMUCL maintainer and I certainly would like to provide Helmut> you a working SLIME for that. But apparently you are the last XEmacs Helmut> user. That's a very small minority. Perhaps the last XEmacs + slime user, but definitely not the last (of the few?) XEmacs users. Helmut> Overall, I think it's wiser and fairer to spend our time on things other Helmut> than XEmacs. I certainly don't want to hold up slime work. I doubt I use slime to it's fullest either. Perhaps this is the final straw.... Ray
On Wed, Jan 08 2014, Raymond Toy wrote:
Helmut> Ray, you are the CMUCL maintainer and I certainly would Helmut> like to provide Helmut> you a working SLIME for that. But apparently you are the Helmut> last XEmacs Helmut> user. That's a very small minority.
Perhaps the last XEmacs + slime user, but definitely not the last (of the few?) XEmacs users.
Yes, that's what I meant.
Helmut> Overall, I think it's wiser and fairer to spend our time Helmut> on things other Helmut> than XEmacs.
I certainly don't want to hold up slime work. I doubt I use slime to it's fullest either.
Perhaps this is the final straw....
It's not the first time that we discuss this. You knew that this day would come eventually. Helmut
"Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:
Helmut> On Wed, Jan 08 2014, Raymond Toy wrote: Helmut> Ray, you are the CMUCL maintainer and I certainly would Helmut> like to provide Helmut> you a working SLIME for that. But apparently you are the Helmut> last XEmacs Helmut> user. That's a very small minority. >> >> Perhaps the last XEmacs + slime user, but definitely not the last (of >> the few?) XEmacs users. Helmut> Yes, that's what I meant. Helmut> Overall, I think it's wiser and fairer to spend our time Helmut> on things other Helmut> than XEmacs. >> >> I certainly don't want to hold up slime work. I doubt I use slime to >> it's fullest either. >> >> Perhaps this is the final straw.... Helmut> It's not the first time that we discuss this. You knew that this day Helmut> would come eventually. I know. :-) But it it ain't broke, don't fix it and xemacs works for what I use it for. Plus decades of cruft in my init files (which are slowly shrinking every time I move to a new box) and xemacsisms and decades of motor memory make it hard. Ray
On Wed, Jan 08 2014, Raymond Toy wrote:
Helmut> It's not the first time that we discuss this. You knew Helmut> that this day Helmut> would come eventually.
I know. :-) But it it ain't broke, don't fix it and xemacs works for what I use it for.
Yes, entirely reasonable decision. OTOH, if M-. doesn't work and #+ infloops then your setup is almost broken.
Plus decades of cruft in my init files (which are slowly shrinking every time I move to a new box) and xemacsisms and decades of motor memory make it hard.
Is there anything that we can do ease a transition? You could send us your .xemacs and we would port it to GNU Emacs :-) Helmut
"Helmut" == Helmut Eller <eller.helmut@gmail.com> writes:
Helmut> On Wed, Jan 08 2014, Raymond Toy wrote: Helmut> It's not the first time that we discuss this. You knew Helmut> that this day Helmut> would come eventually. >> >> I know. :-) But it it ain't broke, don't fix it and xemacs works for >> what I use it for. Helmut> Yes, entirely reasonable decision. OTOH, if M-. doesn't work and #+ Helmut> infloops then your setup is almost broken. It's not really broken. M-. now works, but even before, I didn't use M-. that often. And I don't add #+ very often, and when it does, it doesn't always infloop. Never figured out what the made some different from others. (Which reminds me: I need to figure out a way to have M-. get the right sources when running a snapshot and when running inside my current git tree. This is not a slime issue, I think, but a how I have my cmucl source paths set up.) >> Plus decades of cruft in my init files (which are slowly >> shrinking every time I move to a new box) and xemacsisms and >> decades of motor memory make it hard. Helmut> Is there anything that we can do ease a transition? You could send us Helmut> your .xemacs and we would port it to GNU Emacs :-) Thanks for the generous offer! But it would probably be good for me to do that myself; I'm sure there are numerous (annoying) differences, so it would be best for me find and learn these differences. Besides, I think most of my .xemacs directory is no longer really relevant to even me. :-) Ray
Helmut Eller <eller.helmut@gmail.com> writes:
Plus decades of cruft in my init files (which are slowly shrinking every time I move to a new box) and xemacsisms and decades of motor memory make it hard.
Is there anything that we can do ease a transition? You could send us your .xemacs and we would port it to GNU Emacs :-)
What do you mean *we*??? :-)
Raymond Toy <toy.raymond@gmail.com> writes:
João> Quite amazing that we actually managed to improve the xemacs experience João> by removing support for it...
Heh.
João> But I'm afraid things might get worse sooner rather than later. We'll João> see: keep using slime!
with something cleaner. Otherwise, continuing to use git slime will be a pain to maintain.
I don't know what to say. My personal plans would be to completely remove xemacs support (some 400 of "portability layer" and numerous "(featurep 'xemacs)") hacks that IMO hinder progress greatly. Most of the new features that I planned to introduce wouldn't work on xemacs anyway, as it doesn't have lexical scoping for example. OTOH my focus would be to to work towards modularity (and more firmly establishing it's elisp API) so that new features can be developped more independently. But I'm just a contributor with ideas... What if we branch an xemacs-bugfix-only branch from the current common-lisp-net-cvs branch and apply the "called-interactively-p" fix and maybe a few other fixes you come across. You could maintain that version and I would do my best to help backport bugfixes. That is, until you switch to GNU Emacs :-)
I normally only update slime when quicklisp does.
Maybe one could pin quicklisp to that particular slime branch... João
On Jan 7, 2014, at 19:24 , João Távora <joaot@siscog.pt> wrote:
Raymond Toy <toy.raymond@gmail.com> writes:
João> Quite amazing that we actually managed to improve the xemacs experience João> by removing support for it...
Heh.
João> But I'm afraid things might get worse sooner rather than later. We'll João> see: keep using slime!
with something cleaner. Otherwise, continuing to use git slime will be a pain to maintain.
I don't know what to say.
My personal plans would be to completely remove xemacs support (some 400 of "portability layer" and numerous "(featurep 'xemacs)") hacks that IMO hinder progress greatly. Most of the new features that I planned to introduce wouldn't work on xemacs anyway, as it doesn't have lexical scoping for example.
Wow! I am really behind in Elisp. Since when it has lexical scoping? Cheers — MA
On Wed, Jan 8, 2014 at 2:13 PM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Wow! I am really behind in Elisp. Since when it has lexical scoping?
http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding#toc8 -- Luís Oliveira http://kerno.org/~luis/
On Jan 8, 2014, at 15:33 , Luís Oliveira <luismbo@gmail.com> wrote:
On Wed, Jan 8, 2014 at 2:13 PM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Wow! I am really behind in Elisp. Since when it has lexical scoping?
http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding#toc8
Ok. Sooner or later Emacs will morph into Hemlock 3:) -- Marco Antoniotti
participants (6)
-
Helmut Eller -
joaot＠siscog.pt -
joaotavora＠gmail.com -
Luís Oliveira -
Marco Antoniotti -
Raymond Toy