bug#48535: 28.0.50; ff-find-other-file no longer sets current-buffer?

[Stephen Leake]

There is apparently some change in master relative to 27 in the way
ff-find-other-file works.

First the data from report-emacs-bug:

In GNU Emacs 28.0.50 (build 1, x86_64-w64-mingw32)
 of 2021-05-19 built on TAKVER4
Repository revision: 68f5718c0a4393391ce3c4179e8ab1430e5b0119
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
System Description: Microsoft Windows 8.1 Pro (v6.3.0.9600.20018)

Configured using:
 'configure
 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
ACL DBUS GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: C/*l

Minor modes in effect:
  tooltip-mode: t
  global-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
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils find-file
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs cl-loaddefs cl-lib iso-transl tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table term/w32-win w32-win w32-vars term/common-win 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 easymenu timer select scroll-bar mouse jit-lock
font-lock syntax 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 button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
dbusbind w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 74450 8788)
 (symbols 48 8432 1)
 (strings 32 25401 1600)
 (string-bytes 1 930349)
 (vectors 16 15287)
 (vector-slots 8 197771 11492)
 (floats 8 29 48)
 (intervals 56 237 0)
 (buffers 992 12))


To reproduce:

Copy the two attached files into one directory. Visit a_file.h, position point
after the last line (an elisp sexp in a C comment), type C-x C-e. A new
window opens visiting a_file.c, that buffer is current, as expected.

Now look at the message displayed; it is the result of (current-buffer).
In emacs 27, it is #<buffer a_file.c>, as expected. But in emacs master,
it is #<buffer a_file.h>.

Apparently (ff-find-other-file) returns to the current buffer after
opening the other window, even though the other buffer is current after
the progn finishes?

--
-- Stephe

a_file.h
Description: Binary data

a_file.c
Description: Binary data