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

Previous Next

Package: emacs;

Reported by: Jonathan Holmes <jonathan.m.holmes <at> cantab.net>

Date: Sat, 19 Dec 2015 18:04:01 UTC

Severity: minor

Found in version 24.5

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #10 received at 22212-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Jonathan Holmes <jonathan.m.holmes <at> cantab.net>
Cc: 22212-done <at> debbugs.gnu.org
Subject: Re: bug#22212: 24.5;
 Odd return behavior of function lisp-indent-line (minor)
Date: 21 Dec 2015 10:05:08 -0000
Hello, Jonathan.

In article <mailman.212.1450548248.843.bug-gnu-emacs <at> 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).





This bug report was last modified 9 years and 233 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.