search

liutanyu / mcl

Automatically exported from code.google.com/p/mcl
Other
0 stars 0 forks source link

Lost [Tools] [List Definitions] #16

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Has [Tools] [List Definitions] stopped working?

Original issue reported on code.google.com by p2.edoc@gmail.com on 3 Nov 2009 at 9:51

GoogleCodeExporter commented 8 years ago 
Apparently. (trace ccl::list-definitions) reveals it to return NIL when 
selecting List definitions from the menu, 
even with an editor window full of definitions on top.

Surprisingly, evaluating this works as expected:

(ccl::list-definitions (fred "ccl:lib;list-definitions.lisp"))

Original comment by terje.norderhaug on 4 Nov 2009 at 8:45

GoogleCodeExporter commented 8 years ago 
The problem has to do with whether line endings are encoded as #\Newline or 
#\Linefeed. The list-definitions function detects definitions using a 
primitive search for any line that starts with the string "(def". The 
ccl::%def-string constant holds the match string, with end-of-line as first 
character

In RMCL 5.2, (schar ccl::%def-string 0) is #\Linefeed. As a result, 
list-definitions fails to identify definitions in documents with line endings 
encoded as 
#\Newline.

In MCL 5.2-3, (schar ccl::%def-string 0) is #\Newline. As a result, 
list-definitions fails to identify definitions in documents with line endings 
encoded 
as #\Linefeed.

Where do we go from here? The least invasive might be to change 
#'list-definitions to recognize both #\Newline  and #\Linefeed as EOL. It will 
make it 
take a little longer to get a list of definitions, but with the speed of 
today's hardware, that might not be much of an issue. The alternative is to 
always 
use say #\Linefeed for EOL, but that opens a can of worms.

Original comment by terje.norderhaug on 7 Nov 2009 at 10:00

GoogleCodeExporter commented 8 years ago 
We should check whether the same EOL issue appears in other functionality, like 
where buffer-*-search uses a 
match string with a newline or linefeed character.

Original comment by terje.norderhaug on 7 Nov 2009 at 10:30

GoogleCodeExporter commented 8 years ago 
Here is a candidate fix that makes list-definitions recognize a variety of EOL 
encodings:

(defun list-definitions (w &aux (b (fred-buffer w)) alist)
  "Returns a list of all calls to DEF starting in column 0 with their starting
   positions. Each element of the list is a cons of 2 elements:
    the string of the name being defined and the starting position in the
    buffer of the open paren of the call.
   DEF is case insensitive."
  (do ((pos 0 (buffer-line-start b pos 1))) 
      ((buffer-end-p b pos) (nreverse alist))
      (when (buffer-substring-p b "(def" pos)
        (let ((item (top-form-position-item b (+ pos 4))))
          (when item      
            (push item alist))))))

Original comment by terje.norderhaug on 7 Nov 2009 at 10:53

GoogleCodeExporter commented 8 years ago 
Your magic works perfectly for me Terje. Many thanks.
Fixed afaiac.

Original comment by p2.edoc@gmail.com on 8 Nov 2009 at 4:32

GoogleCodeExporter commented 8 years ago 
Patch uploaded in revision 16da47b998

Original comment by terje.norderhaug on 8 Nov 2009 at 5:29