
Thanks for pointing that out, I guess I hadn't fully considered everything that comes out it being a regexp. It is kind of interesting that assoc-default makes a point of comparing in the appropriate order. Nevertheless, it is now retooled to use find-if and do the string-matching correctly. See any problems now? I have not used elisp much so I'm a bit nervous about the dynamic scoping. As far as I understand it, this should work fine. Tested by calling the function with a variety of arguments, and by connecting with both gnu and xemacs locally and to a remote box. However, all of my machine-instance strings are pretty dull (letters only). As before, there is one patch for just the slime-filename-translations stuff and one patch that also includes everything from "swank-source-files defaults" from 4/2/2006. Nathan Bird -----Original Message----- From: slime-devel-bounces@common-lisp.net [mailto:slime-devel-bounces@common-lisp.net] On Behalf Of Steven E. Harris Sent: Saturday, April 08, 2006 8:03 PM To: slime-devel@common-lisp.net Subject: [slime-devel] Re: slime-filename-translations xemacs-compatability ... Using string-match as the test with assoc* causes some surprising failures. Unlike, say, equal, string-match is asymmetric: the first argument is a regular expression, the second a string. When trying to compare (slime-machine-instance) against itself using string-match, the comparison fails, for (slime-machine-instance) contains regexp meta-characters: ... -- Steven E. Harris _______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel