bug#17320: 24.3.90.1[pretest]; bug-sourcing design-flaw

bug#17320: 24.3.90.1[pretest]; bug-sourcing design-flaw

[Andreas Röhler]

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

bug#17320: 24.3.90.1[pretest]; bug-sourcing design-flaw

[Glenn Morris]

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.