bug#22212: 24.5; Odd return behavior of function lisp-indent-line (minor)

[Alan Mackenzie <acm@muc.de>]

Hello, Jonathan.

In article <mailman.212.1450548248.843.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 160 lines --]

> (lisp-indent-line) generally has an [undocumented] return value of
> (point), but when embedded in structures with a number of commands that move
> the point, it may return nil instead. I learned about the return value
> of (point) from experimentatal evaluation, and then tried to use this to
> write the following function:

> (defun lisp-indent-lines (lnum1 lnum2)
>        (let ((count 0)
>     (pos (point)))
>        (goto-char 0) (forward-line (- lnum1 1))
>        (while (<= lnum1 lnum2)
> (back-to-indentation)
> (setq count (- count (- (point) (lisp-indent-line))))
> (forward-line) (cl-incf lnum1))
>        (goto-char (+ pos count))))

> This exits with a type error because
>      (lisp-indent-line)
> returns nil. But if you execute

>         (setq count 0)
>         (setq count (- count (- (point) (lisp-indent-line))))

> outside of a loop or recursion and outside of let/let* bindings,
> it has no problem. The only problem with

>         (lisp-indent-line)

> is the inconsistent return value, so this isa very minor bug,
> unless it is some kind of esoteric feature used
> in emacs at some phase.

lisp-indent-line's return value is random: it has no significance.  The
function performs its actions, and the value returned is just that of the
last form in lisp-indent-line which happened to be executed.

> The setq statement is not related to the nil value, though it's the
> subtraction by nil in that statement that causes the error -- it will
> also evaluate to nil in working functions that avoid relying on its
> return value.

Can I suggest you actually look at the source code for lisp-indent-line?
It's not difficult to read.  In Emacs 24.5, it's in
emacs/lisp/emacs-lisp/lisp-mode.el at line 1253.  The very last two lines
contain an `if' form: this `if' triggers when point was originally to the
right of the indentation whitespace, and it restores the original
position of point with a `goto-char' form, hence the apparent return
value of point.  If the `if' doesn't trigger (when point started in the
indentation), nil is returned.

Just to emphasise, you cannot rely on the return value of this function.
Instead, you must explicitly use `(point)'.

[ .... ]

Thanks for taking the trouble to report this.  But it isn't really a bug
at all, so I'm closing it.



> In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
>  of 2015-08-20 on lgw01-16, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11501000
> System Description: Ubuntu 14.04.3 LTS

-- 
Alan Mackenzie (Nuremberg, Germany).