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
Description: cperl-mode: Don't reposition frames