* slime.el (slime-find-filename-translators): use assoc* instead of assoc-default. assoc* is out of cl-seq which is in both x and gnu emacs (slime-filename-translations): added a default identity mapping for the system-name as reported by elisp.
Once I fixed the assoc*, I started getting errors when developing entirely locally that it couldn't find a translation for "NATHAN", which is my machine-instance (inventive name isn't it?) correctly reported by ACL. Fix: add a translation for the system-name as reported by the host emacs that just uses identity.
Attached is a diff (filename-translation-compat.diff) to just the slime.el, since I have a separate patch outstanding that also hits the changelog.
There is also a diff (nathanbird-4-2-06.diff) that encompasses this change and the previous one entitled "swank-source-files defaults".
If you need me to resend this patch once you have committed the previous patch or with some other parameters just let me know.
Man, I really like darcs :-)
Nathan Bird
Nathan Bird nathan@acceleration.net writes:
Attached is a diff (filename-translation-compat.diff) to just the slime.el, since I have a separate patch outstanding that also hits the changelog.
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:
(slime-machine-instance)
"torus.sehlabs.com [192.168.1.34]"
(regexp-quote (slime-machine-instance))
"torus\.sehlabs\.com \[192\.168\.1\.34\]"
Next I tried adding the regexp-quoted string to slime-filename-translations:
(push (list (regexp-quote (slime-machine-instance)) 'identity 'identity) slime-filename-translations)
No dice:
(assoc* (slime-machine-instance) slime-filename-translations :test #'string-match)
nil
;; It would work this way: (string-match (caar slime-filename-translations) (slime-machine-instance))
0
;; But we're testing it this way: (string-match (slime-machine-instance) (caar slime-filename-translations))
nil
Even though the slime-filename-translations tuples are supposed to contain a regexp, slime-find-filename-translators is using the car of each as a string and treating (slime-machine-instance) as a regexp.
I think you'll need a test more like:
;; Untested: (defun slime-match-translator (instance regexp) (string-match regexp instance))
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:
...
Nathan Bird nathan@acceleration.net writes:
Nevertheless, it is now retooled to use find-if and do the string-matching correctly. See any problems now?
It looks fine. I'll have to test it again at home later to be sure.
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.
What's holding up these patches being committed? As it stands, the CVS HEAD has been broken for XEmacs for a while now.
Ok, with the new slime froim CVS in an Xemacs I can not load a file nor cd ot another directory because assoc-default is not defined.
The only place in slime.el with assoc-default is: (defun slime-find-filename-translators (hostname) (or (assoc-default hostname slime-filename-translations #'string-match) (error "No filename-translations for hostname: %s" hostname)))
But there is not assoc-defautl defined anywhere. So what is it supposed to to and in which list does it does it's lookup?
Regards Friedrich
Friedrich Dominicus frido@q-software-solutions.de writes:
Ok, with the new slime froim CVS in an Xemacs I can not load a file nor cd ot another directory because assoc-default is not defined.
The only place in slime.el with assoc-default is: (defun slime-find-filename-translators (hostname) (or (assoc-default hostname slime-filename-translations #'string-match) (error "No filename-translations for hostname: %s" hostname)))
Now I wrote a assoc-default (probably dead wrong, but at least it makes it possible to use slime again)
(defun assoc-default (name translations match-fun) (let ((to-match name)) (when (string= name hostname) (setf to-match "")) (loop for translation in translations when (funcall match-fun to-match (car translation)) return (cdr translation))))
I guess you just can call it a hack not a patch. So if anyone knows better, please let me know
Regards Friedrich
-
Friedrich Dominicus -
Nathan Bird -
Steven E. Harris