Don't move to eol in end-of-defun?

[Filipp Gunbin]

In Java, it's a common style to have hanging parentheses:

class C <1>{<2>
  void foo() {
  }<3>
}<4>

If we're at position <1> and press C-M-e, then it's logical to move to
<4>, and that's what I implement in javaimp package, by defining my own
beginning-of-defun-function / end-of-defun-function.  But end-of-defun
first calls (end-of-line 1), before doing everything else, and so my
function finds itself at <2>!  And moves to <3>.

OTOH, end-of-defun is documented to move to "next end of defun", and one
could say that moving from <1> to <3> is just that.  I can agree, but
then I get strange behavior of narrow-to-defun, mark-defun and others,
because they rely on beginning / end of defun.

I can suggest this patch, but I don't very much like it.

Thoughts?

TIA
Filipp


diff --git a/lisp/emacs-lisp/lisp.el b/lisp/emacs-lisp/lisp.el
index 4b85414943..cc8185e453 100644
--- a/lisp/emacs-lisp/lisp.el
+++ b/lisp/emacs-lisp/lisp.el
@@ -507,6 +507,13 @@ end-of-defun-function
 So the function can assume that point is at the beginning of the defun body.
 It should move point to the first position after the defun.")
 
+(defvar end-of-defun-moves-to-eol t
+  "Defines whether `end-of-defun' moves to eol before doing
+everything else.
+
+Set this to nil in major mode if this movement affects mode's
+decisions about context in an unwanted way.")
+
 (defun buffer-end (arg)
   "Return the \"far end\" position of the buffer, in direction ARG.
 If ARG is positive, that's the end of the buffer.
@@ -538,7 +545,9 @@ end-of-defun
         (push-mark))
     (if (or (null arg) (= arg 0)) (setq arg 1))
     (let ((pos (point))
-          (beg (progn (end-of-line 1) (beginning-of-defun-raw 1) (point)))
+          (beg (progn (when end-of-defun-moves-to-eol
+                        (end-of-line 1))
+                      (beginning-of-defun-raw 1) (point)))
          (skip (lambda ()
                  ;; When comparing point against pos, we want to consider that
                  ;; if point was right after the end of the function, it's