bug#47549: 26.3; cperl-mode: buffer view is being re-positioned outside user control

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#47549: 26.3; cperl-mode: buffer view is being re-positioned outside user control

Jim McKim
--text follows this line--

- Starting from 'emacs -Q'

- Invoke CPerl mode via 'M-X cperl-mode'.

- Edit (or create) a buffer that has more lines than the display window.

- Open another window (same size), via 'C-x 5 2'.

- Position the view in that second window to the end of the buffer, via
'ESC->'.

- In the first window, near the top of the buffer, enter this string,
the start of a pair of escaped [] brackets within a perl regexp range:

my $x = qr/[\[\

- Enter the second escaped ']':

my $x = qr/[\[\]

When it is entered, a diagnostic like

  Couldn't find end of charclass in a REx, pos=33584

is displayed in the echo area at the bottom of the edit window and then
the other window displaying that buffer is scrolled (repositioned) back
to the same view as the window being edited, outside the user's control,
abandoning its previous position.

The views, the windows, that are repositioned are those of any latter
part of the buffer.

Peculiarly, identical edits in latter portions of the buffer do not
cause a similar repositioning of top-of-buffer views although they do
generate the diagnostic.

This is just one example of how the repositioning happens. In general,
any edit that results in a message being displayed in the echo area
causes the view to be repositioned.

In the cperl source (git cperl-master), it looks like these
diagnostics are generated via elisp's (message) function. Is this
repositioning a side effect of that function?

The repositioning causes problems when it's important to maintain
multiple views of different parts of a large file. It's like shaking
all the bookmarks out of a reference book, then trying to find the
bookmarked places again.

In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian built on lcy01-amd64-020
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description:     Ubuntu 20.04.2 LTS

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

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-mEZBk7/emacs-26.3+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  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 puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util 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 menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame 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 minibuffer
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 lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 94874 11705)
 (symbols 48 20386 1)
 (miscs 40 44 143)
 (strings 32 28402 800)
 (string-bytes 1 746365)
 (vectors 16 13898)
 (vector-slots 8 500864 9876)
 (floats 8 49 231)
 (intervals 56 262 0)
 (buffers 992 11))

Reply | Threaded
Open this post in threaded view
|

bug#47549: 26.3; cperl-mode: buffer view is being re-positioned outside user control [PATCH]

Harald Jörg
Jim McKim writes:

> - Starting from 'emacs -Q'
>
> - Invoke CPerl mode via 'M-X cperl-mode'.
>
> - Edit (or create) a buffer that has more lines than the display window.
>
> - Open another window (same size), via 'C-x 5 2'.
>
> - Position the view in that second window to the end of the buffer, via
> 'ESC->'.
>
> - In the first window, near the top of the buffer, enter this string,
> the start of a pair of escaped [] brackets within a perl regexp range:
>
> my $x = qr/[\[\
>
> - Enter the second escaped ']':
>
> my $x = qr/[\[\]
>
> When it is entered, a diagnostic like
>
>   Couldn't find end of charclass in a REx, pos=33584
The "pos" in that message should be the character position of the
beginning of the charclass - 33584 seems to be not near the top of the
buffer?  But I guess this isn't relevant - see below.

> is displayed in the echo area at the bottom of the edit window and then
> the other window displaying that buffer is scrolled (repositioned) back
> to the same view as the window being edited, outside the user's control,
> abandoning its previous position.
>
> The views, the windows, that are repositioned are those of any latter
> part of the buffer.
>
> Peculiarly, identical edits in latter portions of the buffer do not
> cause a similar repositioning of top-of-buffer views although they do
> generate the diagnostic.
>
> This is just one example of how the repositioning happens. In general,
> any edit that results in a message being displayed in the echo area
> causes the view to be repositioned.
>
> In the cperl source (git cperl-master), it looks like these
> diagnostics are generated via elisp's (message) function. Is this
> repositioning a side effect of that function?
A similar report occured on Perlmonks recently (coincidence?), and ever
since then I've been trying to reproduce it.  I seem to have collected
some relevant components now, but still fail to construct a situation
where an _inactive_ frame is scrolled:

 - The qr// construct is apparently unclosed.  I'm writing "apparently"
   because somewhere in the following source code there will be a slash
   which cperl-mode takes for closing the qr construct.  There are good
   chances that this occurs outside of the visible portion of the
   screen.

 - cperl-mode writes some diagnostics while its point is at the
   (presumed) end of the qr// construct.  It appears that Emacs tries to
   make that point visible when the message is printed - it scrolls
   forward, changing (window-start) so that the (presumed) end of the
   qr// construct is centered.

 - After the parsing process is done, cperl-mode jumps back to the
   original point - but the original value of (window-start) is lost,
   Emacs now centers the window at the original position.  This makes
   the active frame "jump" which should not happen.

The patch avoids this situation by postponing any output from
`cperl-find-pods-heres' until the code has restored the original window
position.  This works for me in interactive tests.

Unfortunately, I failed to come up with an automated test for that
situation: Batch tests have no window.

--
Cheers,
haj

0001-cperl-mode-Don-t-reposition-the-window-when-writing-.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#47549: 26.3; cperl-mode: buffer view is being re-positioned outside user control [PATCH] fixed!

Harald Jörg
[hidden email] (Harald Jörg) writes:

> [hidden email] (Harald Jörg) writes:
>
>> The patch avoids this situation by postponing any output from
>> `cperl-find-pods-heres' until the code has restored the original window
>> position.  This works for me in interactive tests.
>
> Sorry - the previous message contained a bad patch.  Please use the
> attached patch instead!

Oh my.  It's too late.  This time I forgot to actually attach the patch.
--
Sorry,
haj

0001-cperl-mode-Don-t-reposition-the-window-when-writing-.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#47549: 26.3; cperl-mode: buffer view is being re-positioned outside user control

Lars Ingebrigtsen
[hidden email] (Harald Jörg) writes:

> Oh my.  It's too late.  This time I forgot to actually attach the patch.

:-)

Looks good to me; applied to Emacs 28.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no