source locations are off (Windows)

[gz]

meta-. on, e.g. DEFUN, brings you to a point a few hundred characters after the start of the definition of defun (which happens to be a few hundred lines into its source file). The source file is using the CRLF convention, which is apparently confusing meta-.

[gb]

FWIW, this does seem to be Windows and/or Cocotron-specific.

(On the Mac, if a CRLF-terminated file is compiled without specifying a non-default external-format, source location text will contain CRLFs instead of newlines and file positions won't equal buffer positions, but meta-. seems to be able to often find function and macro definitions, presumably via a fuzzier search. On Windows, things still seem to behave as described above.)

[gb]

Replying to gb:

FWIW, this does seem to be Windows and/or Cocotron-specific.

Or maybe not. My usual init file does SET-DEVELOPMENT-ENVIRONMENT, which causes SOURCE-NOTEs to contain "text" for things define in CCL. I don't have an init file on the Windows system that I tried this on. If I build CCL and the IDE with -n (and if "macros.lisp" is CRLF-terminated), it misbehaves the same way on a Mac.

So: if locations are off (because of line-termination) and there's no source text, meta-. proudly goes to the wrong position and just sits there. That's bad, but it's most likely to most severely affect definitions in CCL sources that're CRLF-terminated. For the user's own sources (where SOURCE-NOTE-TEXT is available), meta-. seems able to find the definition even if CRLF termination causes the position to be wrong, at least in many cases.

This is probably a less severe bug than it initially appeared to be (or at least less likely to affect users.)

[gb]

(In [14480]) Compensate for CRLF line-termination in meta-. Fixes ticket:741, but note that there may be other problems with (e.g.) variable-length character encodings.