GNU bug report logs - #17320
24.3.90.1[pretest]; bug-sourcing design-flaw

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17320 in the body.
You can then email your comments to 17320 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.90.1[pretest]; bug-sourcing design-flaw
Date: Wed, 23 Apr 2014 09:43:38 +0200

When looking for bug #17247

noticed the following

lisp.el, line 374:

    ;; When comparing point against pos, we want to consider that if
    ;; point was right after the end of the function, it's still
    ;; considered as "in that function".
    ;; E.g. `eval-defun' from right after the last close-paren.
    (unless (bolp)
      (skip-chars-forward " \t")
      (if (looking-at "\\s<\\|\n")
          (forward-line 1)))



;;;;;;;;;

A core function should not do that kind of provisions.
Employing forward-line, point might end up at the beginning of valid code, not at the end.
Thus beginning and end of functions are in risk being mixed.

Suggest to drop that and let `eval-defun' etc. make provisions at their needs.

Thanks,

Andreas

GNU Emacs 24.3.90.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2014-04-21

Message #8 received at 17320 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 17320 <at> debbugs.gnu.org
Subject: Re: bug#17320: 24.3.90.1[pretest]; bug-sourcing design-flaw
Date: Tue, 29 Apr 2014 11:47:19 -0400

Andreas Röhler wrote:

> lisp.el, line 374:
>
>     ;; When comparing point against pos, we want to consider that if
>     ;; point was right after the end of the function, it's still
>     ;; considered as "in that function".
>     ;; E.g. `eval-defun' from right after the last close-paren.
>     (unless (bolp)
>       (skip-chars-forward " \t")
>       (if (looking-at "\\s<\\|\n")
>           (forward-line 1)))
>
>
>
> ;;;;;;;;;
>
> A core function should not do that kind of provisions.
> Employing forward-line, point might end up at the beginning of valid
> code, not at the end.
> Thus beginning and end of functions are in risk being mixed.


I do not find your argument compelling, so will close this as wontfix in
a few weeks, unless anyone provides a more convincing justification.

Previous Next

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