bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

[Filipp Gunbin]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

This is in TTY emacs from master (exact commit is below), run in
standard Terminal app under macOS 10.14.5:

emacs -Q -nw

open 2 windows: 

1) (above) some long-running compilation process, put point in the end
so it's constantly scrolled

2) (below) open some buffer (dired, for example) and make Terminal-level
selection, so that the point is inside it

Now, at some point, selection in the lower window becomes garbled,
looking like the line is redrawn, but selection not restored.  This can
be seen in attached screenshot.  This has transient effect, appearing
for a short period of time (few seconds).

Text in the upper window, on the contrary, sometimes becomes "selected",
this is also transient.

Thanks.

In GNU Emacs 27.0.50 (build 17, x86_64-apple-darwin18.6.0, NS appkit-1671.50 Version 10.14.5 (Build 18F132))
 of 2019-06-24 built on fgunbin.local
Repository revision: f3b1b5fb5034de026adc41cf2403cff42f4a0b67
Repository branch: HEAD
System Description:  Mac OS X 10.14.5


[-- Attachment #2: Screenshot 2019-06-24 at 21.56.42.png --]
[-- Type: image/png, Size: 143159 bytes --]

bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Date: Mon, 24 Jun 2019 22:06:41 +0300
> 
> emacs -Q -nw
> 
> open 2 windows: 
> 
> 1) (above) some long-running compilation process, put point in the end
> so it's constantly scrolled
> 
> 2) (below) open some buffer (dired, for example) and make Terminal-level
> selection, so that the point is inside it

What do you mean by Terminal-level selection?  Is that selection by
mouse over TTY frame's text?  If so, I don't think Emacs is sensitive
to that on macOS, it simply doesn't know anything was selected.

> Now, at some point, selection in the lower window becomes garbled,
> looking like the line is redrawn, but selection not restored.  This can
> be seen in attached screenshot.  This has transient effect, appearing
> for a short period of time (few seconds).

Maybe I'm blind, but I don't see any garbage in the screenshot.  Can
you point me to what I am missing?

bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

[Filipp Gunbin]

Eli,

On 25/06/2019 19:13 +0300, Eli Zaretskii wrote:

>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>> Date: Mon, 24 Jun 2019 22:06:41 +0300
>>
>> emacs -Q -nw
>>
>> open 2 windows:
>>
>> 1) (above) some long-running compilation process, put point in the end
>> so it's constantly scrolled
>>
>> 2) (below) open some buffer (dired, for example) and make Terminal-level
>> selection, so that the point is inside it
>
> What do you mean by Terminal-level selection?  Is that selection by
> mouse over TTY frame's text?

Yes.

> If so, I don't think Emacs is sensitive to that on macOS, it simply
> doesn't know anything was selected.

Yes, that's what I expected, and still it somehow produces this
behavior...  I don't insist that it's an Emacs bug, but thought that
reporting it is the right place to start.

>> Now, at some point, selection in the lower window becomes garbled,
>> looking like the line is redrawn, but selection not restored.  This can
>> be seen in attached screenshot.  This has transient effect, appearing
>> for a short period of time (few seconds).
>
> Maybe I'm blind, but I don't see any garbage in the screenshot.  Can
> you point me to what I am missing?

The non-selected line with point on it (happens to be "lisp" line in
dired).  Initially I select the whole area (blue), then sometimes the
line where point resides gets deselected (white, as screenshot
illustrates), sometimes it is selected partially - this gives the
blinking effect and happens while output continues to arrive in another
(Emacs) window.  Just to be clear, it's macOS Terminal in full-screen
mode, with Emacs launched in it, with 2 Emacs windows created as stated.

Thanks,
Filipp.

bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Cc: 36366@debbugs.gnu.org
> Date: Wed, 26 Jun 2019 04:28:37 +0300
> 
> > If so, I don't think Emacs is sensitive to that on macOS, it simply
> > doesn't know anything was selected.
> 
> Yes, that's what I expected, and still it somehow produces this
> behavior...  I don't insist that it's an Emacs bug, but thought that
> reporting it is the right place to start.
> 
> >> Now, at some point, selection in the lower window becomes garbled,
> >> looking like the line is redrawn, but selection not restored.  This can
> >> be seen in attached screenshot.  This has transient effect, appearing
> >> for a short period of time (few seconds).
> >
> > Maybe I'm blind, but I don't see any garbage in the screenshot.  Can
> > you point me to what I am missing?
> 
> The non-selected line with point on it (happens to be "lisp" line in
> dired).  Initially I select the whole area (blue), then sometimes the
> line where point resides gets deselected (white, as screenshot
> illustrates), sometimes it is selected partially - this gives the
> blinking effect and happens while output continues to arrive in another
> (Emacs) window.  Just to be clear, it's macOS Terminal in full-screen
> mode, with Emacs launched in it, with 2 Emacs windows created as stated.

If Emacs is continuously redisplaying, it can legitimately redisplay
the line with point (and also some other lines) from time to time.  If
it does, the selection color will go away, because Emacs knows nothing
about it.

So I don't think this is a bug, you simply shouldn't expect the
selection color to stick in such situations on a TTY frame.

bug#36366: 27.0.50; [macOS] Terminal selection garbled when running compilation in adjacent window

[Filipp Gunbin]

tags 36366 notabug
close 36366
quit

On 26/06/2019 18:25 +0300, Eli Zaretskii wrote:

> If Emacs is continuously redisplaying, it can legitimately redisplay
> the line with point (and also some other lines) from time to time.  If
> it does, the selection color will go away, because Emacs knows nothing
> about it.
>
> So I don't think this is a bug, you simply shouldn't expect the
> selection color to stick in such situations on a TTY frame.

Could it be Terminal's bug then?  Anyway, closing this for now, thanks.

Filipp