Re: lisp-outline-level.

[David Kastrup]

Lute Kamstra <address@hidden> writes:

> In (Emacs) Lisp mode, outline-regexp is ";;;;* [^ \t\n]\\|(" and
> outline-level is lisp-outline-level:
>
> (defun lisp-outline-level ()
>   "Lisp mode `outline-level' function."
>   (if (looking-at "(\\|;;;###autoload")
>       1000
>     (looking-at outline-regexp)
>     (- (match-end 0) (match-beginning 0))))
>
> This is a bit strange as outline-regexp doesn't match
> ";;;###autoload".

Why is that strange?  outline-regexp is not even consulted when
;###autoload is found, so I don't see how it would come into play
here.

> Shall I commit the patch below?

> *** lisp/emacs-lisp/lisp-mode.el      1 Feb 2005 15:48:50 -0000       1.171
> --- lisp/emacs-lisp/lisp-mode.el      13 Feb 2005 11:03:02 -0000
> ***************
> *** 212,223 ****
>   
>   (defun lisp-outline-level ()
>     "Lisp mode `outline-level' function."
> !   (if (looking-at "(\\|;;;###autoload")
>         1000
> -     (looking-at outline-regexp)
>       (- (match-end 0) (match-beginning 0))))
>   
> - 
> --- 212,221 ----
>   
>   (defun lisp-outline-level ()
>     "Lisp mode `outline-level' function."
> !   (if (eq (following-char) ?\()
>         1000
>       (- (match-end 0) (match-beginning 0))))

The patch is completely nonsensical.  It returns rubbish in almost all
cases since it is the "looking-at" that established match-end and
match-beginning in the first place.

However, the original code also is buggy since it returns nonsense in
case outline-regexp does not match at point.  So one should probably
rather write

        (and (looking-at outline-regexp)
             (- (match-end 0) (match-beginning 0)))

as the last lines.  This will return "nil" instead of a nonsensical
value in case there is no match at point.  I don't know how and where
lisp-outline-level is used, so maybe some other value (1000?) would be
more appropriate than nil.  But returning some random value (which
includes a segmentation violation, by the way) in case that none of
the two looking-at expressions succeeded does not seem like a good
idea in any case.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum