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