pinard/Pymacs

latest Pymacs cannot load ropemacs

Closed this issue · 3 comments

My Pymacs of 2011-12-15 loads ropemacs nicely. I just installed the latest Pymacs and ran:

(pymacs-load "ropemacs" "rope-")

after this, ropemacs-local-keymap is still undefined.

Any idea what might break it? Thanks.

leoliu
reply@reply.github.com
writes:

My Pymacs of 2011-12-15 loads ropemacs nicely. I just installed the latest Pymacs and ran:
(pymacs-load "ropemacs" "rope-")
after this, ropemacs-local-keymap is still undefined.
Any idea what might break it? Thanks.

Hi! Not much, as I'm not much familiar with Rope. The problem might be
located in Pymacs, Emacs or Ropemacs, not to make things easier.

I would start by checking the contents of the Pymacs buffer within
Emacs, to see which kind of interaction happened between Ropemacs and
Emacs through Pymacs. There should be traces in there of the
installation of the keymap. I would then check if the map was installed
as requested, and try to seek more hints or comprehension from there.

Good courage in your exploration!

François

ropemacs checks pymacs.py which no longer exists

diff -r 7af544334b85 ropemacs/__init__.py
--- a/ropemacs/__init__.py  Fri Dec 17 21:51:54 2010 +0300
+++ b/ropemacs/__init__.py  Mon Feb 06 01:14:22 2012 +0800
@@ -568,7 +568,7 @@
     while frame:
         # checking frame.f_code.co_name == 'pymacs_load_helper' might
         # be very fragile.
-        if inspect.getfile(frame).rstrip('c').endswith('pymacs.py'):
+        if inspect.getfile(frame).rstrip('c').endswith('Pymacs.py'):
             return True
         frame = frame.f_back

Hi! Leo.

Indeed, Pymacs/init.py and Pymacs/pymacs.py are now gone, and have been both replaced with a single Pymacs.py. The idea was to get a simpler Pymacs structure to ease python-mode installation. I used a capital as a way to make sure the API did not change for users. However, inspecting like above goes far beyond what the API promises. So I presume Ropemacs had a need that the API does not cover, and had no choice than to develop a fragile solution for it

I'm not here to say whose fault it is, and in any case, I'm sorry for the inconvenience my change created. As discussed on the Rope mailing list, it is better to use "... .endswith(('Pymacs.py', 'pymacs.py'))" to cope with Pymacs both before and after the change. Even better would be to find a way (if possible?) which stays within the Pymacs API.

François