common-lisp-indent'ation of def*

common-lisp-indent'ation of def*

[Juanma Barranquero]

Drew Adams sent me the following problem with the common-lisp-indent code:

 ;; evaluate this
  (progn
   (unless (assoc "cl-indent" load-history)
     (load "cl-indent"))
   (set (make-local-variable 'lisp-indent-function)
        'common-lisp-indent-function)
   (put 'if 'common-lisp-indent-function
        '(nil nil &body)))

 (if ()
     (deffoo bar
   ())              ;; indent this
   (foo bar))

 => Wrong type argument: number-or-marker-p, (8 241)

`lisp-indent-line' fails because `calculate-lisp-indent' is returning
a list with '((8 241) 241), which, according to its docstring, it
shouldn't. The docstring says that the return value is either an
integer, or (COLUMN CONTAINING-SEXP-START).

`common-lisp-indent-function-1' is determining that `deffoo' has no
*lisp-indent-function property, but as it starts with `def', treats it
as a tentative defun, so it sends it to
`common-lisp-indent-call-method', which in turns sends it to
`lisp-indent-259', which returns the weird value.

So, is this a bug in `lisp-indent-line' (and the docstring of
`calculate-lisp-indent'), and '((8 241) 241) should be treated as
valid? Or, OTOH, it is a bug in `common-lisp-indent-function' and
friends?

-- 
                    /L/e/k/t/u

Re: common-lisp-indent'ation of def*

[Richard Stallman]

    So, is this a bug in `lisp-indent-line' (and the docstring of
    `calculate-lisp-indent'), and '((8 241) 241) should be treated as
    valid? Or, OTOH, it is a bug in `common-lisp-indent-function' and
    friends?

Since the callers of `lisp-indent-line' fail when it returns such a
value, I conclude they agree with its documentation.  So I conclude
that the bug is in `common-lisp-indent-function' and its subroutines.

Re: common-lisp-indent'ation of def*

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     So, is this a bug in `lisp-indent-line' (and the docstring of
>     `calculate-lisp-indent'), and '((8 241) 241) should be treated as
>     valid? Or, OTOH, it is a bug in `common-lisp-indent-function' and
>     friends?
>
> Since the callers of `lisp-indent-line' fail when it returns such a
> value, I conclude they agree with its documentation.  So I conclude
> that the bug is in `common-lisp-indent-function' and its subroutines.

I concur.  I've checked in a fix.

Re: common-lisp-indent'ation of def*

[Juanma Barranquero]

On 10/26/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> I concur.  I've checked in a fix.

Thanks.

Now I'm seeing something weird. After eval'ing the progn, doing M-C-q
at the start of the if gives:

 (if ()
     (deffoo bar
	 ()) ;; indent this
     (foo bar))

However, hitting TAB in each line gives:

 (if ()
     (deffoo bar
	 ()) ;; indent this
   (foo bar))

Is that expected?

-- 
                    /L/e/k/t/u

Re: common-lisp-indent'ation of def*

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Now I'm seeing something weird. After eval'ing the progn, doing M-C-q
> at the start of the if gives:
>
> (if ()
>     (deffoo bar
> 	 ()) ;; indent this
>     (foo bar))
>
> However, hitting TAB in each line gives:
>
> (if ()
>     (deffoo bar
> 	 ()) ;; indent this
>   (foo bar))
>
> Is that expected?

No.  I've checked in a fix for the fix.  I think it's right, but the
code in cl-indent.el is pretty grungy :-(

Re: common-lisp-indent'ation of def*

[Juanma Barranquero]

On 10/27/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> I've checked in a fix for the fix.

Yeah, now it works. Thanks.

> I think it's right, but the
> code in cl-indent.el is pretty grungy :-(

That's why I just reported the bug. I love cl*.el, but the code makes me dizzy.

-- 
                    /L/e/k/t/u

Re: common-lisp-indent'ation of def*

[Stefan Monnier]

> That's why I just reported the bug. I love cl*.el, but the code makes
> me dizzy.

Yup.  Lucky it doesn't have any confusing comments ;-)


        Stefan

Re: common-lisp-indent'ation of def*

[Juanma Barranquero]

On 10/27/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yup.  Lucky it doesn't have any confusing comments ;-)

No, and I consider myself lucky if I don't find many more like this one:

;;; Future notes:

;; Once Emacs 19 becomes standard, many things in this package which are
;; messy for reasons of compatibility can be greatly simplified.  For now,
;; I prefer to maintain one unified version.

Emacs 19... I *really* wonder if these "messy things" were ever simplified.

-- 
                    /L/e/k/t/u

Re: common-lisp-indent'ation of def*

[Richard Stallman]

    ;;; Future notes:

    ;; Once Emacs 19 becomes standard, many things in this package which are
    ;; messy for reasons of compatibility can be greatly simplified.  For now,
    ;; I prefer to maintain one unified version.

    Emacs 19... I *really* wonder if these "messy things" were ever simplified.

Probably not.  Can you identify the things we were going to change?
That way we could do so, for after the release.

Re: common-lisp-indent'ation of def*

[Juanma Barranquero]

On 10/28/06, Richard Stallman <rms@gnu.org> wrote:

> Probably not.  Can you identify the things we were going to change?
> That way we could do so, for after the release.

I don't think anyone but the original author can; at least, not
easily. We're talking about 4000+ lines of quite complex code with
almost no comments. It's a little project in itself.

-- 
                    /L/e/k/t/u

Re: common-lisp-indent'ation of def*

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 10/28/06, Richard Stallman <rms@gnu.org> wrote:
>
>> Probably not.  Can you identify the things we were going to change?
>> That way we could do so, for after the release.
>
> I don't think anyone but the original author can; at least, not
> easily. We're talking about 4000+ lines of quite complex code with
> almost no comments. It's a little project in itself.

Sounds like something that could be worth doing for a "Google summer
of code" project if something like this comes up again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum