bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Philipp Stephani]

Assume there's a file /tmp/Foo.java:

$ cat /tmp/Foo.java 
class Foo {
  void bar() {
    // body
  }
}

Emacs 26:

$ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn (search-forward "// body") (print (which-function)))'

"bar"


Emacs 27 pretest:

$ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn (search-forward "// body") (print (which-function)))'

"class Foo"


That is, Emacs 27 now prints the clas name instead of the method name.
I think the Emacs 26 behavior is preferrable.


In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
 of 2020-02-25
Repository revision: 03c07c88d90b5747456b9d286bace2dd4a713aac
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux rodete

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --enable-gcc-warnings=warn-only
 --enable-gtk-deprecation-warnings --without-pop --with-mailutils
 --enable-checking --enable-check-lisp-object-type --with-modules
 'CFLAGS=-O0 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
XDBE XIM MODULES THREADS PDUMPER GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec epa epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton
derived edmacro kmacro pcase ffap thingatpt url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
subr-x rx gnutls puny seq byte-opt gv bytecomp byte-compile cconv dbus
xml cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 59465 7934)
 (symbols 48 8079 1)
 (strings 32 20894 1643)
 (string-bytes 1 680049)
 (vectors 16 12053)
 (vector-slots 8 164854 5050)
 (floats 8 26 33)
 (intervals 56 196 0)
 (buffers 1000 11))

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Philipp.

In article <mailman.2226.1583586546.2412.bug-gnu-emacs@gnu.org> you wrote:

> Assume there's a file /tmp/Foo.java:

> $ cat /tmp/Foo.java 
> class Foo {
>   void bar() {
>     // body
>   }
> }

> Emacs 26:

> $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> (search-forward "// body") (print (which-function)))'

> "bar"


> Emacs 27 pretest:

> $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> (search-forward "// body") (print (which-function)))'

> "class Foo"


> That is, Emacs 27 now prints the clas name instead of the method name.
> I think the Emacs 26 behavior is preferrable.

OK.  which-function works by trying out a whole series of functions and
returning the first result which is non-nil.  CC Mode is now returning a
non-nil value (namely "class Foo") for one of these functions where it
previously didn't.

There're things like backward compatibility (with what exactly, I'm not
sure) to take into account before changing things here.

I'll look more closely into this in the coming days.

> In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
>  of 2020-02-25
> Repository revision: 03c07c88d90b5747456b9d286bace2dd4a713aac
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
> System Description: Debian GNU/Linux rodete

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Philipp.

On Sat, Mar 07, 2020 at 14:07:42 +0100, Philipp Stephani wrote:

> Assume there's a file /tmp/Foo.java:

> $ cat /tmp/Foo.java 
> class Foo {
>   void bar() {
>     // body
>   }
> }

> Emacs 26:

> $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn (search-forward "// body") (print (which-function)))'

> "bar"


> Emacs 27 pretest:

> $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn (search-forward "// body") (print (which-function)))'

> "class Foo"


> That is, Emacs 27 now prints the clas name instead of the method name.
> I think the Emacs 26 behavior is preferrable.

Yes, indeed.

Just in passing, lisp/progmodes/which-func.el could do with a serious
amount of tender loving care.  I reported a bug about it this morning,
and enclose a rough workaround fix to another one in this post.

> In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
>  of 2020-02-25
> Repository revision: 03c07c88d90b5747456b9d286bace2dd4a713aac
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
> System Description: Debian GNU/Linux rodete

CC Mode's support for "name of function at point" is somewhat
bedraggled, too.  It gets mixed up with c-defun-tactic, the option which
instructs CC Mode to use the current function within the next enclosing
class, etc., rather than the top level thing.

CC Mode's support includes two different functionalities: one intended
for interactive display (triggered by C-c C-z), the other intended for
add-change-log-entry-other-window (C-x 4 a).  I can't actually see why
the second of these is different from the first.  However,
which-function has been using this second of these.

A rough patch to CC Mode is as follows:



diff -r 2c9f4cff0753 cc-mode.el
--- a/cc-mode.el	Fri Apr 03 20:04:29 2020 +0000
+++ b/cc-mode.el	Sun Apr 19 13:37:22 2020 +0000
@@ -778,7 +778,8 @@
     (make-local-variable 'add-log-current-defun-function)
     (setq add-log-current-defun-function
 	  (lambda ()
-	    (or (c-cpp-define-name) (c-defun-name)))))
+	    (or (c-cpp-define-name) 
+		(car (c-defun-name-and-limits nil))))))
 
   (let ((rfn (assq mode c-require-final-newline)))
     (when rfn


However, there is a problem in which-function, where when one puts point
after the final } in your test file, it reports "bar" on the mode line.
It really should indicate "no function" or, at a pinch, "class Foo".
The problem here is in `which-function', where it keeps trying different
methods until it finds one which returns non-nil.  The last of these
methods is a search of the imode list, which contains only "bar".

Here is a very rough workaround, which might form the basis of a proper
fix at some stage.



diff --git a/lisp/progmodes/which-func.el b/lisp/progmodes/which-func.el
index 1cee552b0c..9be629dafd 100644
--- a/lisp/progmodes/which-func.el
+++ b/lisp/progmodes/which-func.el
@@ -282,6 +282,11 @@ which-function
     (when (null name)
       (setq name (add-log-current-defun)))
     ;; If Imenu is loaded, try to make an index alist with it.
+;;;; NEW STOUGH, 2020-04-19
+    ;; If `add-log-current-defun' ran and gave nil, accept this.
+    (when (and (null name)
+               (null add-log-current-defun-function))
+;;;; END OF NEW STOUGH
     (when (and (null name)
 	       (boundp 'imenu--index-alist)
                (or (null imenu--index-alist)
@@ -328,6 +333,9 @@ which-function
                              (funcall
                               which-func-imenu-joiner-function
                               (reverse (cons (car pair) namestack))))))))))))
+;;;; NEW STOUGH, 2020-04-19
+    )
+;;;; END OF NEW STOUGH
     ;; Filter the name if requested.
     (when name
       (if which-func-cleanup-function


-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Philipp.

On Sun, Mar 08, 2020 at 11:33:02 -0000, Alan Mackenzie wrote:
> In article <mailman.2226.1583586546.2412.bug-gnu-emacs@gnu.org> you wrote:

> > Assume there's a file /tmp/Foo.java:

> > $ cat /tmp/Foo.java 
> > class Foo {
> >   void bar() {
> >     // body
> >   }
> > }

> > Emacs 26:

> > $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> > (search-forward "// body") (print (which-function)))'

> > "bar"


> > Emacs 27 pretest:

> > $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> > (search-forward "// body") (print (which-function)))'

> > "class Foo"


> > That is, Emacs 27 now prints the clas name instead of the method name.
> > I think the Emacs 26 behavior is preferrable.

[ .... ]

> I'll look more closely into this in the coming days.

I've committed two patches to savannah master which I hope have fixed
this.  One was to CC Mode, the other to lisp/progmodes/which-func.el.

Could you possibly try out these and let me know whether they have, in
fact, fixed the problem.  Thanks!

> > In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.12, cairo version 1.16.0)
> >  of 2020-02-25
> > Repository revision: 03c07c88d90b5747456b9d286bace2dd4a713aac
> > Repository branch: master
> > Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
> > System Description: Debian GNU/Linux rodete

> [ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Philipp Stephani]

Am Mi., 20. Mai 2020 um 21:13 Uhr schrieb Alan Mackenzie <acm@muc.de>:
>
> Hello, Philipp.
>
> On Sun, Mar 08, 2020 at 11:33:02 -0000, Alan Mackenzie wrote:
> > In article <mailman.2226.1583586546.2412.bug-gnu-emacs@gnu.org> you wrote:
>
> > > Assume there's a file /tmp/Foo.java:
>
> > > $ cat /tmp/Foo.java
> > > class Foo {
> > >   void bar() {
> > >     // body
> > >   }
> > > }
>
> > > Emacs 26:
>
> > > $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> > > (search-forward "// body") (print (which-function)))'
>
> > > "bar"
>
>
> > > Emacs 27 pretest:
>
> > > $ emacs -Q -batch -l which-func /tmp/Foo.java -eval '(progn
> > > (search-forward "// body") (print (which-function)))'
>
> > > "class Foo"
>
>
> > > That is, Emacs 27 now prints the clas name instead of the method name.
> > > I think the Emacs 26 behavior is preferrable.
>
> [ .... ]
>
> > I'll look more closely into this in the coming days.
>
> I've committed two patches to savannah master which I hope have fixed
> this.  One was to CC Mode, the other to lisp/progmodes/which-func.el.
>
> Could you possibly try out these and let me know whether they have, in
> fact, fixed the problem.  Thanks!

Seems to work as expected, thanks.
Do you think you could push these patches onto the release branch, as
this appears to be a regression?

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 21 May 2020 17:56:16 +0200
> Cc: 39972@debbugs.gnu.org
> 
> Do you think you could push these patches onto the release branch, as
> this appears to be a regression?

The fixes (especially the one for which-func) are too risky for the
release branch.  Is it possible to come up with something simpler for
emacs-27?  What change(s) caused the regression, exactly?

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Philipp Stephani]

Am Do., 21. Mai 2020 um 18:15 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Thu, 21 May 2020 17:56:16 +0200
> > Cc: 39972@debbugs.gnu.org
> >
> > Do you think you could push these patches onto the release branch, as
> > this appears to be a regression?
>
> The fixes (especially the one for which-func) are too risky for the
> release branch.  Is it possible to come up with something simpler for
> emacs-27?  What change(s) caused the regression, exactly?

git bisect says the commit that broke this was
[0613e7a38efc3b0534e0ca5c5fa401e2a3bda906] which-function: Do not
display outdated imenu information

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Philipp Stephani]

Am Do., 21. Mai 2020 um 19:24 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Do., 21. Mai 2020 um 18:15 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Thu, 21 May 2020 17:56:16 +0200
> > > Cc: 39972@debbugs.gnu.org
> > >
> > > Do you think you could push these patches onto the release branch, as
> > > this appears to be a regression?
> >
> > The fixes (especially the one for which-func) are too risky for the
> > release branch.  Is it possible to come up with something simpler for
> > emacs-27?  What change(s) caused the regression, exactly?
>
> git bisect says the commit that broke this was
> [0613e7a38efc3b0534e0ca5c5fa401e2a3bda906] which-function: Do not
> display outdated imenu information

See also the discussion about
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33695, which was fixed
by this commit.

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Eli.

On Thu, May 21, 2020 at 19:15:42 +0300, Eli Zaretskii wrote:
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Thu, 21 May 2020 17:56:16 +0200
> > Cc: 39972@debbugs.gnu.org

> > Do you think you could push these patches onto the release branch, as
> > this appears to be a regression?

> The fixes (especially the one for which-func) are too risky for the
> release branch.  Is it possible to come up with something simpler for
> emacs-27?

See below.

> What change(s) caused the regression, exactly?

class Foo {
    void bar() {
    // body      <============== Point is here.
    }
}


Traditionally, the function which-function (in which-func.el) has tried a
row of methods to find the current function, stopping after finding the
first non-null result.

Emacs 26's CC Mode's value of add-log-current-defun returned nil, after
which which-function tried querying the imenu structures, which worked
OK.

emacs-27's CC Mode's value of add-log-current-defun now returns the top
level function, "class Foo".  which-function no longers proceeds to the
imenu stuff.  "class Foo" is here the result returned by which-function.
This is not OK.

master's CC Mode's value of add-log-current-defun now returns "bar".

The remainder of the recent patch to which-function ensures that if
add-log-current-defun IS ACTUALLY CALLED and returns nil, this nil
becomes which-function's result.  There were previously problems where
add-log-current-defun had returned nil because point was outside any
function, yet imenu would later return a spurious function name.

> Is it possible to come up with something simpler for emacs-27?

I think the change (in master) to CC Mode's value of
add-log-current-defun could be put into emacs-27 on its own.  This should
be safe.

The patch which made this change (bug #39972) was:
5989432d15feb4439e759d2c0e28233ca22a7604
"CC Mode: Fix bug #39972, by fixing c-display-defun-name for nested
defuns"
Date:   Wed May 20 19:02:26 2020 +0000.

What do you say to putting this into emacs-27?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Eli Zaretskii]

> Date: Thu, 21 May 2020 17:42:11 +0000
> Cc: Philipp Stephani <p.stephani2@gmail.com>, 39972@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Is it possible to come up with something simpler for emacs-27?
> 
> I think the change (in master) to CC Mode's value of
> add-log-current-defun could be put into emacs-27 on its own.  This should
> be safe.
> 
> The patch which made this change (bug #39972) was:
> 5989432d15feb4439e759d2c0e28233ca22a7604
> "CC Mode: Fix bug #39972, by fixing c-display-defun-name for nested
> defuns"
> Date:   Wed May 20 19:02:26 2020 +0000.
> 
> What do you say to putting this into emacs-27?

If it fixes the problem reported in this bug report, it's fine by me
to cherry-pick it to emacs-27.

Thanks.

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Thu, 21 May 2020 19:24:15 +0200
> Cc: Alan Mackenzie <acm@muc.de>, 39972@debbugs.gnu.org
> 
> > The fixes (especially the one for which-func) are too risky for the
> > release branch.  Is it possible to come up with something simpler for
> > emacs-27?  What change(s) caused the regression, exactly?
> 
> git bisect says the commit that broke this was
> [0613e7a38efc3b0534e0ca5c5fa401e2a3bda906] which-function: Do not
> display outdated imenu information

Thanks for investigating this.

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Eli.

On Thu, May 21, 2020 at 22:14:24 +0300, Eli Zaretskii wrote:
> > Date: Thu, 21 May 2020 17:42:11 +0000
> > Cc: Philipp Stephani <p.stephani2@gmail.com>, 39972@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Is it possible to come up with something simpler for emacs-27?

> > I think the change (in master) to CC Mode's value of
> > add-log-current-defun could be put into emacs-27 on its own.  This should
> > be safe.

> > The patch which made this change (bug #39972) was:
> > 5989432d15feb4439e759d2c0e28233ca22a7604
> > "CC Mode: Fix bug #39972, by fixing c-display-defun-name for nested
> > defuns"
> > Date:   Wed May 20 19:02:26 2020 +0000.

> > What do you say to putting this into emacs-27?

> If it fixes the problem reported in this bug report, it's fine by me
> to cherry-pick it to emacs-27.

I've just tried it, and it almost fixes the problem.  :-(

With that commit cherry-picked to emacs-27, visit the Java file:

class Foo {
    void bar() {
    // body
    }
}

, and enable which-function-mode.  When point is within class Foo or bar,
which-function-mode reports "class Foo" or "bar" correctly.

But when point is _after_ the terminating brace of class Foo, "bar" is
wrongly reported.  I now remember that this is the reason for my
amendment to which-func.el.

Sorry to trouble you with such a minor point, but I'm unable to decide
myself whether such a small bug should prevent the cherry-picking of
5989432 into emacs-27.  I'm leaning towards doing the cherry-pick.

So, please help me by making the decision.  Thanks!

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Eli Zaretskii]

> Date: Thu, 21 May 2020 20:19:35 +0000
> Cc: p.stephani2@gmail.com, 39972@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> class Foo {
>     void bar() {
>     // body
>     }
> }
> 
> , and enable which-function-mode.  When point is within class Foo or bar,
> which-function-mode reports "class Foo" or "bar" correctly.
> 
> But when point is _after_ the terminating brace of class Foo, "bar" is
> wrongly reported.  I now remember that this is the reason for my
> amendment to which-func.el.
> 
> Sorry to trouble you with such a minor point, but I'm unable to decide
> myself whether such a small bug should prevent the cherry-picking of
> 5989432 into emacs-27.  I'm leaning towards doing the cherry-pick.
> 
> So, please help me by making the decision.  Thanks!

I agree with you.

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Alan Mackenzie]

Hello, Eli.

On Fri, May 22, 2020 at 08:58:17 +0300, Eli Zaretskii wrote:
> > Date: Thu, 21 May 2020 20:19:35 +0000
> > Cc: p.stephani2@gmail.com, 39972@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > Sorry to trouble you with such a minor point, but I'm unable to decide
> > myself whether such a small bug should prevent the cherry-picking of
> > 5989432 into emacs-27.  I'm leaning towards doing the cherry-pick.

> > So, please help me by making the decision.  Thanks!

> I agree with you.

Thanks.  I've committed the cherry-pick to the emacs-27 branch.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#39972: 28.0.50; which-function no longer returning current Java method in Emacs 27

[Philipp Stephani]

Am Fr., 22. Mai 2020 um 11:58 Uhr schrieb Alan Mackenzie <acm@muc.de>:
>
> Hello, Eli.
>
> On Fri, May 22, 2020 at 08:58:17 +0300, Eli Zaretskii wrote:
> > > Date: Thu, 21 May 2020 20:19:35 +0000
> > > Cc: p.stephani2@gmail.com, 39972@debbugs.gnu.org
> > > From: Alan Mackenzie <acm@muc.de>
>
> [ .... ]
>
> > > Sorry to trouble you with such a minor point, but I'm unable to decide
> > > myself whether such a small bug should prevent the cherry-picking of
> > > 5989432 into emacs-27.  I'm leaning towards doing the cherry-pick.
>
> > > So, please help me by making the decision.  Thanks!
>
> > I agree with you.
>
> Thanks.  I've committed the cherry-pick to the emacs-27 branch.

Thanks, closing.