Happens always, even the first time after a full recompile, no files modified. ----- Original message ----- From: "Andrew Myers" <asm198@gmail.com> To: mhd@yv.org Cc: slime-devel@common-lisp.net Date: Thu, 27 Oct 2011 11:13:18 -0400 Subject: Re: [slime-devel] meta-. off by several lines on SLIME/ACL/Emacs/Windows, anyone seen this? Have you modified the file since you last compile it? When this happens it usually means the version of the file that's compile into the image is older than what's on disk. On Thu, Oct 27, 2011 at 10:05 AM, <mhd@yv.org> wrote:

When I do meta-., it takes me there, but it's off by several lines, and at a random place in the middle of the line. I think it's consistently above the def.  But not by the same amount of lines each time. And I'm in a random part of the line.  Should be at the beginning, right? It's stable in a session: two repeated meta-.'s take me to the same place each time. Admittedly, I've not any home work on versions of SLIME/Emacs/ACL/Windows. Not asking for anyone to do any more than say if they recall anything like this. I use SBCL and CCL with the otherwise-same stack with no similar problems

_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel

2011/10/27 Helmut Eller:

* mhd@yv.org [2011-10-27 14:05] writes:

...

When I do meta-., it takes me there, but it's off by several lines, and at a random place in the middle of the line. I think it's consistently above the def.  But not by the same amount of lines each time. And I'm in a random part of the line.  Should be at the beginning, right? It's stable in a session: two repeated meta-.'s take me to the same place each time. Admittedly, I've not any home work on versions of SLIME/Emacs/ACL/Windows. Not asking for anyone to do any more than say if they recall anything like this. I use SBCL and CCL with the otherwise-same stack with no similar problems

The problem may be that ACL counts end-of-line (crlf) as 2 characters while Emacs counts it as 1 (or vice-versa).  A simple test case would be useful.

From experience, ACL >= 8.1 counts ends-of-line as 1 character even with CRLF.

mhd, try redefining `slime-eol-conversion-fixup' to always return 0. Paulo Madeira

2011/10/27 Mark H. David:

Yes, that worked. Thanks.

Any thoughts on a real solution?

I should add that I'm also using Swank to talk to ACL in a different process. Maybe that's always how you do SLIME with ACL, I'm kinda new at this. But anyhow, I don't usually use Swank with the other Lisps (SBCL, CCL), so I guess that's another difference.

A solution that allows you to work with several implementations simultaneously can go through inspecting which is the implementation of the current connection. I have advised `slime-eol-conversion-fixup' in Emacs to do this, it does the job: (defadvice slime-eol-conversion-fixup (around sc-eol-fixup-acl>=8.1 activate) (if (and (not (boundp 'notes)) ; compilation notes (string-equal "allegro" (slime-lisp-implementation-name)) (>= (string-to-number (slime-lisp-implementation-version)) 8.1)) (setq ad-return-value 0) ad-do-it)) However, I don't like the idea of having implementation-specific code in Slime (Emacs side), directly or indirectly. Moreover, there's that (boundp 'notes) hack (it's actually just a normal bound variable somewhere up the stack...), because somehow compiler notes still count CRLF ends-of-line as 2 instead of 1. A real solution could be aiding the fixup with Swank, such as appending a value to the xref result(s), compiler notes and everywhere else with a file reference, indicating if CRLF files should count ends-of-line as 2. For instance, ACL >= 8.1 would say CRLF ends-of-line are 1 when returning xref's but it would say EOL's are 2 when returning compiler notes. Paulo Madeira