Re: Emacs enters in a loop with emacsclient -t

[Eli Zaretskii]

> From: address@hidden (Ashish SHUKLA)
> Date: Sun, 03 Mar 2013 09:37:15 +0530
> 
> I'm running Emacs trunk r111924 on FreeBSD 9.1-RC3 (amd64). When I connect to
> Emacs session using 'emacsclient -t', I noticed flicker in xterm. I truss-ed
> Emacs process, and it seems like it's sending same stuff in a loop which seems
> to be causing what I noticed:

Thanks.

First, please post this to address@hidden, using the Emacs
command report-emacs-bug.  That way, this issue and all the ensuing
discussions are recorded and tracked by the Emacs bug tracker.

And second, please accompany such data with snapshots of the Emacs
frame and description of what was displayed and which mode(s) were in
effect in the displayed windows, when you collected the truss data.
Without this information, the truss data is useless, as it doesn't
even say enough to understand which part(s) of the display are being
redrawn and cause the flicker.

> write(23,"\^[[50d\^[[38;5;252m\^[[48;5;17m"...,330) = 330 (0x14a)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"_error\^[[39;49m\^[[38;5;252m\^["...,202) = 202 (0xca)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,1024) = 1024 (0x400)
> write(23,"[39;49m\^[[38;5;252m\^[[48;5;17m"...,143) = 143 (0x8f)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"49m\^[[38;5;84m\^[[48;5;17mservn"...,487) = 487 (0x1e7)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"                                "...,258) = 258 (0x102)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    h"...,880) = 880 (0x370)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    h"...,765) = 765 (0x2fd)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,822) = 822 (0x336)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,957) = 957 (0x3bd)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,153) = 153 (0x99)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,937) = 937 (0x3a9)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,576) = 576 (0x240)

See, all I can say given this is that you use xterm-256, and here
Emacs is redrawing something like 11 lines with background color 17
and foreground color 252.  I see some small parts of text, like
"_error" and "servn", but that is not enough to understand what is
going on.

> write(23,"\^[[50d\^[[38;5;252m\^[[48;5;17m"...,330) = 330 (0x14a)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"_error\^[[39;49m\^[[38;5;252m\^["...,202) = 202 (0xca)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,1024) = 1024 (0x400)
> write(23,"[39;49m\^[[38;5;252m\^[[48;5;17m"...,143) = 143 (0x8f)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"49m\^[[38;5;84m\^[[48;5;17mservn"...,487) = 487 (0x1e7)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,1024) = 1024 (0x400)
> write(23,"                                "...,258) = 258 (0x102)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    h"...,880) = 880 (0x370)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    h"...,765) = 765 (0x2fd)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,822) = 822 (0x336)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m    "...,957) = 957 (0x3bd)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,153) = 153 (0x99)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,937) = 937 (0x3a9)
> write(23,"\n\^[[38;5;252m\^[[48;5;17m     "...,576) = 576 (0x240)

Here the same stuff is being redrawn, some 13 milliseconds after the
previous redisplay.

That's all I can deduce from this data.  Maybe someone else can see
what I cannot.

> The flicker stops, when I focus the X11 frame, and do some activity there, and
> resumes when I focus back to xterm.

Was the stuff shown in the X11 frame related in any way to what was
shown in the xterm frame?  Like the same buffer, perhaps?

> I'm wondering if anyone else has noticed it, or know of a fix to the problem.

I think we are very far from understanding this problem, let alone
find a solution for it.  Providing the missing information (as a bug
report) would be a good first step forward.