all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#19776: 25.0.50; HTML rendering is very slow
@ 2015-02-04 23:03 Richard Stallman
  2015-02-05 11:42 ` Nicolas Richard
                   ` (2 more replies)
  0 siblings, 3 replies; 90+ messages in thread
From: Richard Stallman @ 2015-02-04 23:03 UTC (permalink / raw)
  To: 19776


The automatic HTML rendering of the following message takes several
seconds on this X60 which for most things is blindingly fast.
Since there is no indication on the screen of what is happening,
I think that I failed to type a command, and type it again.

It needs to be sped up, but in the short term it needs to display
"Rendering html..." in the echo area.


Date: Tue, 3 Feb 2015 17:34:46 -0500 (EST)
From: The Nation Magazine <emails@emails.thenation.com>
Message-ID: <20150203223446.3769712.187000@sailthru.com>
Subject: Anti-Vaxxers and Our Political Craziness Gap, Plus: Emotional Labor
 at McDonald's and the Super Bowl Conspiracy Theory
Content-Type: multipart/alternative; 
	boundary="----=_Part_52339185_374501655.1423002886144"

------=_Part_52339185_374501655.1423002886144
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.=
w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns=3D"http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" />
<meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=3D1.=
0"/>
<title>Email Nation</title>
<style type=3D"text/css">
*{margin-top:0;margin-bottom:0;padding:0;border:0;line-height:normal;outlin=
e:0;list-style:none;font-family:Arial,Helvetica,sans-serif;-webkit-text-siz=
e-adjust:none}body{margin-top:0!important;margin-bottom:0!important;padding=
-top:0!important;padding-bottom:0!important;width:100%!important;-webkit-te=
xt-size-adjust:100%!important;-ms-text-size-adjust:100%!important;-webkit-f=
ont-smoothing:antialiased!important}img{border:0!important;outline:none!imp=
ortant}
table{border-collapse:collapse;mso-table-lspace:0;mso-table-rspace:0}
td{border-collapse:collapse;mso-line-height-rule:exactly}
a{border-collapse:collapse;mso-line-height-rule:exactly}
span{border-collapse:collapse;mso-line-height-rule:exactly}.ExternalClass=
=20
*{line-height:100%}.ExternalClass,.ExternalClass p,.ExternalClass span,.Ext=
ernalClass font,.ExternalClass td,.ExternalClass a,.ExternalClass=20
div{line-height:100%}.mob=20
a{color:#000;text-decoration:none}.footer_text1=20
a{color:#000;text-decoration:none}
@media only screen and (max-width:480px){
table[class=3Dwrapper]{width:100%!important}
table[class=3Dmain_table]{width:320px!important}
td[class=3Dmin_width]{min-width:320px!important}
td[class=3Daside]{width:15px!important}
td[class=3Dspc_height]{height:15px!important}
td[class=3Dspc_20]{height:20px!important}
td[class=3Dhide]{display:none!important}
img[class=3Dhide]{display:none!important}
span[class=3Dhide]{display:none!important}
table[class=3Dhide]{display:none!important}
td[class=3Dtext]{text-align:center!important}
td[class=3Dpad_top]{padding-top:20px!important}
img[class=3Dful_width]{width:100%!important;height:auto!important}
td[class=3Dpad_both]{padding-left:45px!important;padding-right:45px!importa=
nt}
table[class=3Dwid_160]{width:160px!important}
td[class=3Dmob_width1]{width:158px!important}
td[class=3Dmob_width2]{width:130px!important}
td[class=3Dspc_30]{height:30px!important}
td[class=3Dconnect]{padding-left:15px!important;padding-right:15px!importan=
t;font-size:20px!important;line-height:25px!important}td[class=3Dfooter_tex=
t1]{padding-left:12px!important;padding-right:12px!important}}
</style>
</head>
<body marginwidth=3D"0" marginheight=3D"0" style=3D"margin-top: 0;=20
margin-bottom: 0; padding-top: 0; padding-bottom: 0;   width: 100% !importa=
nt;-webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; background-c=
olor:#fffffe; -webkit-font-smoothing: antialiased; " offset=3D"0" topmargin=
=3D"0" leftmargin=3D"0" bgcolor=3D"#fffffe">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center" bgcolor=3D"#fffffe">
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREHEADER & MASTHEAD =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" cellpadding=3D"0" cellspacing=3D"0" align=3D"center">
<tr><td height=3D"5" valign=3D"top" align=3D"center" style=3D"font-family: =
arial, san-serif; font-size: 1px; color:#fffffe;line-height:5px;">A minimal=
ly responsible Republican Party would not pander to this sort of thing. But=
 that, of course, is not what we have.</td></tr>
<tr><td valign=3D"top" align=3D"center" style=3D"font-family: arial, san-se=
rif; font-size: 10px; color:#666666;">Having trouble reading this email? <a=
 href=3D"http://link.thenation.com/view/53481ca417ffdeb835293bf128sq8.40ag/=
302eeb0d" target=3D"_blank" style=3D"color: #FF0E00 !important;">View it on=
 the Web.</a></td></tr>
<tr><td height=3D"5" style=3D"line-height:1px;font-size:1px;">&nbsp;</td></=
tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MASTHEAD =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"283" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"main_table">
<tr>
<td width=3D"20" class=3D"aside">&nbsp;</td>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"center"><a href=3D"http://link.thenation.com/53481ca417ffdeb83=
5293bf128sq8.40ag/Tc2PvcTjHfFPa1KfB3b56" target=3D"_blank"><img src=3D"http=
://email-media.s3.amazonaws.com/TheNation/EmailNation/logo_242x35.png" alt=
=3D"" width=3D"242" height=3D"35" style=3D"display:block;" border=3D"0" /><=
/a></td>
</tr>
<tr>
<td height=3D"7" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"center" class=3D"text" style=3D"font-family:Arial,sans-serif;c=
olor:#000001;font-size:15px;line-height:18px;text-decoration:none;font-weig=
ht:bold;">Tuesday, February 03, 2015</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
<td width=3D"20" class=3D"aside">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<tr>
<td bgcolor=3D"#d25340" style=3D"line-height:0px;font-size:0px;" height=3D"=
1"><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/sp=
acer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"0"=
 /></td>
</tr>
<tr>
<td bgcolor=3D"#e0e0e0" style=3D"min-width:606px;" class=3D"min_width">
<table width=3D"606" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"main_table">
<!-- =3D=3D=3D=3D=3D MAIN CONTENT =3D=3D=3D=3D=3D -->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#d7d7d7" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#cecece" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#c2c2c2" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#ffffff">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td width=3D"13" class=3D"aside">&nbsp;</td>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FEATURE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td height=3D"20" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"335" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNEg6cPo1o7muBpxAfac9" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/vaccine_rtr_img.jpg" alt=3D"" width=3D"335" class=
=3D"ful_width"  style=3D"display:block;" border=3D"0" /></a></td>
</tr>
<tr>
<td height=3D"20" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"220" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNEg6cPo1o7muBpxAfac9" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;">The GOP=E2=80=99s Em=
brace of Anti-Vaxxers Reveals the Craziness Gap in American Politics</a></t=
d>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Mi=
chelle Goldberg </td>
</tr>
<tr>
<td height=3D"25" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"220" height=3D"40">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/blog/196857/=
gops-embrace-anti-vaxxers-reveals-craziness-gap-american-politics" style=3D=
"height:40px;v-text-anchor:middle;width:220px;" arcsize=3D"15%" stroke=3D"f=
" fill=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_feature_220x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read More >></center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNEg6cPo1o7muBpxAfac9"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_feature_220x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:220px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td bgcolor=3D"#d25340" style=3D"line-height:0px;font-size:0px;" height=3D"=
1"><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/sp=
acer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"0"=
 /></td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AD #1 - leaderboard =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td height=3D"20" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"center"><!-- BEGIN GOOGLE DFP AD UNIT--><!-- <a href=3D"http:/=
/link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag/U0V-8sPoc577FPPsBe0e=
4"><img src=3D"http://pubads.g.doubleclick.net/gampad/ad?iu=3D/1004953/emai=
l_nation_leaderboard&sz=3D568x73&c=3D12345" class=3D"ful_width" /> </a>--> =
<!-- END GOOGLE DFP AD UNIT--> <!--ORIGINAL TEMPLATE AD: <a href=3D"xxxx" t=
arget=3D"_blank"><img src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/image_2_568x73.png" alt=3D"xxxx" width=3D"568" height=3D"73" cl=
ass=3D"ful_width" style=3D"display:block;" border=3D"0" /></a>--><a href=3D=
"http://link.thenation.com/fl/53481ca417ffdeb835293bf128sq8.40ag/538f3f2ea8=
9eecc42f000004/546f942f5f1d5b0a2f2c09ab/67d33d29"><img src=3D"http://link.t=
henation.com/fl/53481ca417ffdeb835293bf128sq8.40ag/538f3f2ea89eecc42f000004=
/546f942f5f1d5b0a2f2c09ab/67d33d29.gif" alt=3D"" width=3D"570" height=3D"70=
" border=3D"0" class=3D"adflight-banner" /></a></td>
</tr>
<tr>
<td height=3D"20" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNDUasPo4IPwqPeTAa4cb" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/mcdonalds_pay_with_lovin_sg_img.png" alt=3D"" width=
=3D"277" style=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a>=
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNDUasPo4IPwqPeTAa4cb" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >A Job at McDonald=
=E2=80=99s Now Includes Singing and Dancing on Demand</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Br=
yce Covert </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/blog/196777/=
mcdonalds-demands-emotional-labor-new-pay-lovin-campaign" style=3D"height:4=
0px;v-text-anchor:middle;width:278px;" arcsize=3D"15%" stroke=3D"f" fill=3D=
"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNDUasPo4IPwqPeTAa4cb"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Donations =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#c2c2c2"  height=3D"1" style=3D"line-height:0px;font-size:0p=
x;" ><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/=
spacer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"=
0" /></td>
</tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#c2c2c2"   style=3D"line-height:0px;font-size:0px;" width=3D=
"1" ></td>
<td bgcolor=3D"#e0e0e0">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"14">&nbsp;</td>
</tr>
<tr>
<td align=3D"center"><a href=3D"http://link.thenation.com/53481ca417ffdeb83=
5293bf128sq8.40ag/U1bn08PolQK1AO3UB34ef" target=3D"_blank" style=3D"font-fa=
mily:Georgia, 'Times New Roman', Times, serif;color:#de1f27;font-size:28px;=
line-height:30px;text-decoration:none;font-weight:bold;font-style:italic;">=
Donate</a></td>
</tr>
<tr>
<td align=3D"center"><a href=3D"http://link.thenation.com/53481ca417ffdeb83=
5293bf128sq8.40ag/Uo45GcJSMz3AoXH8Ba24e" target=3D"_blank" style=3D"font-fa=
mily:Georgia, 'Times New Roman', Times, serif;color:#666666;font-size:18px;=
line-height:20px;text-decoration:none;font-weight:bold;font-style:italic;">=
Donations Make This Journalism Possible</a></td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"14">&nbsp;</td>
</tr>
</table>
</td>
<td bgcolor=3D"#c2c2c2"   style=3D"line-height:0px;font-size:0px;" width=3D=
"1" ></td>
</tr>
</table>
</td>
</tr>
<tr>
<td bgcolor=3D"#c2c2c2"  height=3D"1" style=3D"line-height:0px;font-size:0p=
x;" ><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/=
spacer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"=
0" /></td>
</tr>
</table>
</td>
</tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNEg6cPo1o7muBpyA0781" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/russell_wilson_superbowl_ap_img.jpg" alt=3D"" width=
=3D"277" style=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a>=
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNEg6cPo1o7muBpyA0781" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >The Conspiracy Theo=
ry Surrounding The Seahawks=E2=80=99 Last Play</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Da=
ve Zirin </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/blog/196697/=
conspiracy-theory-surrounding-seahawks-last-play%23" style=3D"height:40px;v=
-text-anchor:middle;width:278px;" arcsize=3D"15%" stroke=3D"f" fill=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNEg6cPo1o7muBpyA0781"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr><td  style=3D"line-height:0px;font-size:0px;" height=3D"1" bgcolor=3D"#=
d25340">&nbsp;</td></tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VM-7JcPooQCe779dAd657" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/fort_lauderdale_homeless_charity_ap_img.jpg" alt=3D=
"" width=3D"277" style=3D"display:block;"  class=3D"ful_width"  border=3D"0=
" /></a></td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VM-7JcPooQCe779dAd657" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >The City That Outla=
wed Free Food</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Mi=
chelle Chen </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/blog/196689/=
city-outlawed-free-food" style=3D"height:40px;v-text-anchor:middle;width:27=
8px;" arcsize=3D"15%" stroke=3D"f" fill=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VM-7JcPooQCe779dAd657"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONNECT WITH THE NATION #1=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#c2c2c2"  height=3D"1" style=3D"line-height:0px;font-size:0p=
x;" ><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/=
spacer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"=
0" /></td>
</tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#c2c2c2"   style=3D"line-height:0px;font-size:0px;" width=3D=
"1" ></td>
<td bgcolor=3D"#e0e0e0">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"14">&nbsp;</td>
</tr>
<tr>
<td align=3D"center"  style=3D"font-family:Georgia, 'Times New Roman', Time=
s, serif;color:#818181;font-size:22px;line-height:25px;text-decoration:none=
;font-weight:bold;font-style:italic;" class=3D"pad_both">Connect with The N=
ation on</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"12">&nbsp;</td>
</tr>
<tr>
<td align=3D"center" >
<table width=3D"340" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wrapper">
<tr>
<td>
<table width=3D"160" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td>
<table width=3D"160" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/UuwGyuYQKU6Dv0fvB377c" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_1_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"11">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#495b96;font-size:21px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/UuwGyuYQKU6Dv0fvCe8a9" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#495b96;font-size:21px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Facebook</a></td>
</tr>
</table>
</td>
</tr>
</table>
<table width=3D"140" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td class=3D"pad_top">
<table width=3D"140" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/Ulg_JsJSXnuzy19vB5ef8" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_2_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"11">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#64a9df;font-size:21px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/Ulg_JsJSXnuzy19vCb760" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#64a9df;font-size:21px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Twitter</a></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"14">&nbsp;</td>
</tr>
</table>
</td>
<td bgcolor=3D"#c2c2c2"   style=3D"line-height:0px;font-size:0px;" width=3D=
"1" ></td>
</tr>
</table>
</td>
</tr>
<tr>
<td bgcolor=3D"#c2c2c2"  height=3D"1" style=3D"line-height:0px;font-size:0p=
x;" ><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/=
spacer1x1.gif" width=3D"1" height=3D"1" style=3D"display:block;" border=3D"=
0" /></td>
</tr>
</table>
</td>
</tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VM-sU8Po_XyS39ocA185c" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/drone_wot_ap_img_0.jpg" alt=3D"" width=3D"277" styl=
e=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a></td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VM-sU8Po_XyS39ocA185c" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >7 Reasons Why Ameri=
ca=E2=80=99s Wars Aren=E2=80=99t Ending Anytime Soon</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Wi=
lliam Astore </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/article/1967=
05/seven-reasons-why-americas-wars-arent-ending-anytime-soon" style=3D"heig=
ht:40px;v-text-anchor:middle;width:278px;" arcsize=3D"15%" stroke=3D"f" fil=
l=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VM-sU8Po_XyS39ocA185c"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr><td  style=3D"line-height:0px;font-size:0px;" height=3D"1" bgcolor=3D"#=
d25340">&nbsp;</td></tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNEMpMPooQCe9qdOAc269" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/vietnam_war_protest_ap_img.jpg" alt=3D"" width=3D"2=
77" style=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a></td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNEMpMPooQCe9qdOAc269" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >Why Is There No Mas=
sive Antiwar Movement in America?</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by To=
m Engelhardt </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/article/1968=
17/why-there-no-massive-antiwar-movement-america" style=3D"height:40px;v-te=
xt-anchor:middle;width:278px;" arcsize=3D"15%" stroke=3D"f" fill=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNEMpMPooQCe9qdOAc269"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr><td  style=3D"line-height:0px;font-size:0px;" height=3D"1" bgcolor=3D"#=
d25340">&nbsp;</td></tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNDUasPo4IPwqPeSAf28c" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/bob_dylan_france_2012_ap_img.jpg" alt=3D"" width=3D=
"277" style=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a></t=
d>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNDUasPo4IPwqPeSAf28c" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >Some Enchanted Stan=
dards</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by Da=
vid Hajdu </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/article/1967=
93/some-enchanted-standards" style=3D"height:40px;v-text-anchor:middle;widt=
h:278px;" arcsize=3D"15%" stroke=3D"f" fill=3D"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNDUasPo4IPwqPeSAf28c"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ARTICLE =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr><td  style=3D"line-height:0px;font-size:0px;" height=3D"1" bgcolor=3D"#=
d25340">&nbsp;</td></tr>
<tr><td height=3D"15" style=3D"line-height:1px;font-size:1px;">&nbsp;</td><=
/tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"277" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag=
/VNEMpMPooQCe9qdUAd3c2" target=3D"_blank"><img src=3D"http://www.thenation.=
com/sites/default/files/tmw2015-02-04colorlarge.jpg" alt=3D"" width=3D"277"=
 style=3D"display:block;"  class=3D"ful_width"  border=3D"0" /></a></td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
<table width=3D"278" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"right" class=3D"wrapper">
<tr>
<td align=3D"left"><a href=3D"http://link.thenation.com/53481ca417ffdeb8352=
93bf128sq8.40ag/VNEMpMPooQCe9qdUAd3c2" target=3D"_blank" style=3D"font-fami=
ly:Georgia, 'Times New Roman', Times, serif;color:#000001;font-size:18px;li=
ne-height:22px;text-decoration:none;font-weight:bold;" >What to Do Now That=
 Republicans Have Acknowledged Climate Change</a></td>
</tr>
<tr>
<td height=3D"5" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#496a8b;font-size:15px;li=
ne-height:18px;text-decoration:none;font-weight:bold;" align=3D"left">by To=
m Tomorrow </td>
</tr>
<tr>
<td height=3D"12" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
<tr>
<td align=3D"left" width=3D"278">
<div><!--[if mso]>
<v:roundrect xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schem=
as-microsoft-com:office:word" href=3D"http://www.thenation.com/blog/196561/=
what-do-now-republicans-have-acknowledged-climate-change" style=3D"height:4=
0px;v-text-anchor:middle;width:278px;" arcsize=3D"15%" stroke=3D"f" fill=3D=
"t">
<v:fill type=3D"tile" src=3D"http://email-media.s3.amazonaws.com/TheNation/=
EmailNation/button_article_278x40.jpg" color=3D"#fa1b20" />
<w:anchorlock/>
<center style=3D"color:#ffffff;font-family:sans-serif;font-size:13px;font-w=
eight:bold;">Read &raquo;</center>
</v:roundrect>
<![endif]--><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128=
sq8.40ag/VNEMpMPooQCe9qdUAd3c2"
style=3D"background-color:#fa1b20;background-image:url(http://email-media.s=
3.amazonaws.com/TheNation/EmailNation/button_article_278x40.jpg);border-rad=
ius:6px;color:#ffffff;display:inline-block;font-family:Tahoma,Geneva,Arial,=
sans-serif;font-size:18px;font-weight:bold;line-height:40px;text-align:cent=
er;text-decoration:none;width:278px;-webkit-text-size-adjust:none;mso-hide:=
all;font-style:italic;">Read &raquo;</a></div>
</td>
</tr>
<tr>
<td height=3D"15" style=3D"line-height:0px;font-size:0px;" >&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"1">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IN OUR ORBIT =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D-->
<!--                            <tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td width=3D"156" valign=3D"top" style=3D"font-family:Tahoma, sans-serif;co=
lor:#000001;font-size:24px;line-height:26px;text-decoration:none;font-weigh=
t:bold;" class=3D"mob_width1" >In Our Orbit</td>
<td width=3D"13">&nbsp;</td>
<td width=3D"405" valign=3D"top" class=3D"mob_width2">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"left">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"10" >&nbsp;</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"8" bgcolor=3D"#0000=
01" ><img src=3D"http://email-media.s3.amazonaws.com/TheNation/EmailNation/=
spacer1x1.gif" width=3D"1" height=3D"8" style=3D"display:block;" border=3D"=
0" /></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td width=3D"20" class=3D"hide">&nbsp;</td>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"15" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#de1f27;font-size:16px;li=
ne-height:20px;text-decoration:none;font-weight:bold;">Stop Watching Us</td=
>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"5" >&nbsp;</td>
</tr>
<tr>
<td style=3D"font-family:Tahoma, sans-serif;color:#000001;font-size:13px;li=
ne-height:16px;text-decoration:none;" class=3D"mob">The Stop Watching Us Ra=
lly Against Mass Surveillance being held in Washington, DC, this Saturday, =
October 26, the twelfth anniversary of the Patriot Act, is expected to be t=
he largest privacy protest in the history of the republic. Formed in June 2=
013, the StopWatching.us coalition comprises more than 100 public advocacy =
organizations from across the political spectrum demanding that Congress in=
vestigate the full extent of the NSA's spying programs. <span class=3D"hide=
" style=3D"font-family:Tahoma, sans-serif;color:#000001;font-size:13px;line=
-height:16px;text-decoration:none;">Find out how you can join the march and=
 support the cause <a href=3D"xxxx" target=3D"_blank" style=3D"font-family:=
Tahoma, sans-serif;color:#000001;font-size:13px;line-height:16px;text-decor=
ation:underline;">here</a>.</span></td>
</tr>
</table>
</td>
<td width=3D"24" class=3D"hide">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"40"  class=3D"spc_3=
0">&nbsp;</td>
</tr>
</table>
</td>
</tr>
-->
<!-- end IN OUR ORBIT -->
</table>
</td>
<td width=3D"13" class=3D"aside">&nbsp;</td>
</tr>
</table>
</td>
<td bgcolor=3D"#c2c2c2" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#cecece" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#d7d7d7" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
</tr>
</table>
</td>
</tr>
<!-- end MAIN CONTENT-->
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONNECT WITH THE NATION #2 =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#e0e0e0">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"30">&nbsp;</td>
</tr>
<tr>
<td align=3D"center"  style=3D"font-family:Georgia, 'Times New Roman', Time=
s, serif;color:#818181;font-size:22px;line-height:25px;text-decoration:none=
;font-weight:bold;font-style:italic;" class=3D"connect" >Connect with The N=
ation<span class=3D"hide" style=3D"font-family:Georgia, 'Times New Roman', =
Times, serif;color:#818181;font-size:22px;line-height:25px;text-decoration:=
none;font-weight:bold;font-style:italic;"> on</span></td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"16">&nbsp;</td>
</tr>
<tr>
<td align=3D"center" >
<table width=3D"582" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wrapper">
<tr>
<td>
<table width=3D"164" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td>
<table width=3D"164" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/UuwGyuYQKU6Dv0fvD9872" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_1_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"8">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#495b96;font-size:20px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/UuwGyuYQKU6Dv0fvE1220" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#495b96;font-size:20px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Facebook</a></td>
</tr>
</table>
</td>
</tr>
</table>
<!--[if gte mso 9]>
</td>
<td valign=3D"top">
<![endif]-->
<table width=3D"142" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td class=3D"pad_top">
<table width=3D"142" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/Ulg_JsJSXnuzy19vD8443" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_2_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"8">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#64a9df;font-size:20px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/Ulg_JsJSXnuzy19vE0cbe" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#64a9df;font-size:20px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Twitter</a></td>
</tr>
</table>
</td>
</tr>
</table>
<!--[if gte mso 9]>
</td>
<td valign=3D"top">
<![endif]-->
<table width=3D"155" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td class=3D"pad_top">
<table width=3D"155" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/U0MimcPoCFztEvPABe752" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_3_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"11">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#c94b3b;font-size:20px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/U0MimcPoCFztEvPACd925" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#c94b3b;font-size:20px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Google+</a></td>
</tr>
</table>
</td>
</tr>
</table>
<!--[if gte mso 9]>
</td>
<td valign=3D"top">
<![endif]-->
<table width=3D"120" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"left" class=3D"wrapper">
<tr>
<td class=3D"pad_top">
<table width=3D"120" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" align=
=3D"center" class=3D"wid_160">
<tr>
<td width=3D"40"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293=
bf128sq8.40ag/U0MimcPoCFztEvPBB469e" target=3D"_blank"><img src=3D"http://e=
mail-media.s3.amazonaws.com/TheNation/EmailNation/icon_4_40x40.png" alt=3D"=
" width=3D"40" height=3D"40" style=3D"display:block;" border=3D"0" /></a></=
td>
<td width=3D"11">&nbsp;</td>
<td align=3D"left" valign=3D"middle" style=3D"font-family:Tahoma, sans-seri=
f;color:#3d485d;font-size:20px;line-height:25px;text-decoration:none;font-w=
eight:bold;"><a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf12=
8sq8.40ag/U0MimcPoCFztEvPBC81e7" target=3D"_blank" style=3D"font-family:Tah=
oma, sans-serif;color:#3d485d;font-size:20px;line-height:25px;text-decorati=
on:none;font-weight:bold;">Tumblr</a></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"35">&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
<!-- end CONNECT WITH THE NATION #2 -->
<!--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DFOOTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D-->
<tr>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td bgcolor=3D"#d7d7d7" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#cecece" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#ffffff">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td width=3D"20">&nbsp;</td>
<td>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" alig=
n=3D"center">
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"18">&nbsp;</td>
</tr>
<tr>
<td align=3D"center"><a href=3D"http://link.thenation.com/53481ca417ffdeb83=
5293bf128sq8.40ag/Tc2PvcTjHfFPa1KfCde3f" target=3D"_blank"><img src=3D"http=
://link.thenation.com/img/53481ca417ffdeb835293bf128sq8.40ag/fa4560f2.gif" =
alt=3D"" width=3D"101" style=3D"display:block;" border=3D"0" /></a></td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"18">&nbsp;</td>
</tr>
<tr>
<td align=3D"center" style=3D"font-family:Arial,sans-serif;color:#000001;fo=
nt-size:12px;line-height:18px;text-decoration:none;" class=3D"footer_text1"=
>To unsubscribe from all Nation emails or to update your email preferences,=
 <a href=3D"http://link.thenation.com/oc/53481ca417ffdeb835293bf128sq8.40ag=
/c3903959">click here</a>.<br />
<br />
<a href=3D"http://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag/TZI=
-7oO8Fi0BuqI0Bf2ad" target=3D"_blank" style=3D"font-family:Arial,sans-serif=
;color:#000001;font-size:12px;line-height:18px;text-decoration:underline;">=
Privacy Policy</a> &nbsp;|&nbsp; <a href=3D"http://link.thenation.com/53481=
ca417ffdeb835293bf128sq8.40ag/TZI-7oO8Fi0CuqI0B381a" target=3D"_blank" styl=
e=3D"font-family:Arial,sans-serif;color:#000001;font-size:12px;line-height:=
18px;text-decoration:underline;">Contact Us</a> &nbsp;|&nbsp; <a href=3D"ht=
tp://link.thenation.com/53481ca417ffdeb835293bf128sq8.40ag/TZI-7oO8Fi0DuqI0=
B8f0d" target=3D"_blank" style=3D"font-family:Arial,sans-serif;color:#00000=
1;font-size:12px;line-height:18px;text-decoration:underline;">How to Advert=
ise</a> &nbsp;|&nbsp; <a href=3D"http://link.thenation.com/53481ca417ffdeb8=
35293bf128sq8.40ag/U1bn08PolQK1AO3UCc895" target=3D"_blank" style=3D"font-f=
amily:Arial,sans-serif;color:#000001;font-size:12px;line-height:18px;text-d=
ecoration:underline;">Donate</a> &nbsp;|&nbsp; <a href=3D"http://link.thena=
tion.com/53481ca417ffdeb835293bf128sq8.40ag/U_9ySsPohX11TpP9B093f" target=
=3D"_blank" style=3D"font-family:Arial,sans-serif;color:#000001;font-size:1=
2px;line-height:18px;text-decoration:underline;">Subscribe</a><br />
<br />
The Nation Magazine<br />
33 Irving Place<br />
New York, NY 10003
</td>
</tr>
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"23">&nbsp;</td>
</tr>
</table>
</td>
<td width=3D"20">&nbsp;</td>
</tr>
</table>
</td>
<td bgcolor=3D"#e0e0e0" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#c2c2c2" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#cecece" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
<td bgcolor=3D"#d7d7d7" style=3D"line-height:0px;font-size:0px;" width=3D"1=
" class=3D"hide"></td>
</tr>
</table>
</td>
</tr>
<!-- end of FOOTER -->
<tr>
<td  style=3D"line-height:0px;font-size:0px;" height=3D"46">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<!--//////BODY && FOOTER-->
</table>
<!--//Emailer ends here-->
</body>
</html>

------=_Part_52339185_374501655.1423002886144--






In GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2015-02-01 on rms
System Description:	Trisquel GNU/Linux 6.0.1, Toutatis

Configured using:
 `configure 'CFLAGS=-g3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  abbrev-mode: t

Recent messages:
Wrote /home/rms/outgoing/out-35
Saving file /home/rms/outgoing/out-35...
Wrote /home/rms/outgoing/out-35
Expunging deleted messages...done
Char: TAB (9, #o11, #x9) point=150 of 52916 (0%) column=0
Mark set [2 times]
Saved text until "rt_52339185_374501655.1423002886144--


"

Load-path shadows:
None found.

Features:
(shadow emacsbug rmailout shell pcomplete grep compile comint
ansi-color ring url-util url-parse auth-source cl-macs eieio byte-opt
gv bytecomp byte-compile cl-extra seq cconv eieio-core cl-generic
gnus-util password-cache url-vars shr-color color shr dom cl-loaddefs
cl-lib subr-x pcase browse-url mailalias rmailsum battery qp rmailmm
message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired
t-mouse package epg-config view time-date paren cus-start cus-load
advice help-fns tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
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
make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

Memory information:
((conses 8 273262 23081)
 (symbols 24 22796 0)
 (miscs 20 634 1310)
 (strings 16 30913 4808)
 (string-bytes 1 1005054)
 (vectors 8 14300)
 (vector-slots 4 415483 37376)
 (floats 8 295 462)
 (intervals 28 52132 83)
 (buffers 520 27)
 (heap 1024 9349 544))
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-02-04 23:03 bug#19776: 25.0.50; HTML rendering is very slow Richard Stallman
@ 2015-02-05 11:42 ` Nicolas Richard
  2015-02-05 16:14   ` Eli Zaretskii
  2015-12-25 22:34 ` Lars Ingebrigtsen
  2021-10-27 12:59 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 90+ messages in thread
From: Nicolas Richard @ 2015-02-05 11:42 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 19776

Richard Stallman <rms@gnu.org> writes:
> The automatic HTML rendering of the following message takes several
> seconds on this X60 which for most things is blindingly fast.

FWIW, here's the elp-results on my machine (after instrumenting the
package shr, and calling shr-render-buffer) :
shr-descend                          6227        408.78522387  0.0656472175
shr-tag-table                        1062        189.46034310  0.1783995697
shr-tag-table-1                      1062        189.33667913  0.1782831253
shr-make-table                       3186        187.52006959  0.0588575234
shr-make-table-1                     1070        164.06574762  0.1533324744
shr-render-td                        3428        163.98280975  0.0478362922
shr-render-buffer                    1           28.734523319  28.734523319
shr-insert-document                  1           28.712268988  28.712268988
shr-tag-body                         1           28.690722764  28.690722764
shr-insert-table                     1062        0.8013559019  0.0007545724
shr-insert                           4126        0.283103186   6.861...e-05
shr-tag-a                            822         0.2324357269  0.0002827685
shr-column-specs                     1062        0.1266108010  0.0001192192
shr-tag-div                          198         0.0957929849  0.0004838029
shr-max-columns                      2124        0.0947569080  4.461...e-05
shr-colorize-region                  634         0.075634319   0.0001192970
shr-parse-style                      548         0.0700457249  0.0001278206
shr-color-check                      141         0.0599092470  0.0004248882
shr-tag-img                          333         0.058440363   0.0001754965
shr-color-visible                    141         0.0464957430  0.0003297570
shr-urlify                           212         0.0396780100  0.0001871604
shr-count                            5966        0.0346115289  5.801...e-06
shr-table-widths                     1062        0.0337347569  3.176...e-05
shr-add-font                         3462        0.0260796149  7.533...e-06
shr-find-fill-point                  494         0.0245121429  4.961...e-05
shr-indent                           10019       0.0231243120  2.308...e-06
shr-remove-trailing-whitespace       1           0.02058152    0.02058152
shr-pro-rate-columns                 1062        0.0123682060  1.164...e-05
shr-insert-table-ruler               4045        0.0103226100  2.551...e-06
shr-ensure-paragraph                 1064        0.0096426120  9.062...e-06
shr-color->hexadecimal               282         0.0084433179  2.994...e-05
shr-fold-text                        23          0.0077441709  0.0003367030
shr-ensure-newline                   396         0.0067178849  1.696...e-05
shr-expand-url                       545         0.0023009930  4.222...e-06
shr-tag-br                           102         0.002192799   2.149...e-05
shr-tag-comment                      289         0.0007590249  2.626...e-06
shr-tag-title                        1           0.00071629    0.00071629
shr-heading                          1           0.000702604   0.000702604
shr-encode-url                       46          0.0006519919  1.417...e-05
shr-fontize-dom                      1           0.000606771   0.000606771
shr-tag-span                         9           0.000584241   6.491...e-05
shr-previous-newline-padding-width   126         0.0004090820  3.246...e-06
shr-image-displayer                  23          8.367...e-05  3.638...e-06
shr-tag-style                        1           2.438e-06     2.438e-06

> Since there is no indication on the screen of what is happening,
> I think that I failed to type a command, and type it again.
>
> It needs to be sped up, but in the short term it needs to display
> "Rendering html..." in the echo area.

A patch is attached but I don't know if this is the right place for it
(shr-insert-document).

modified   lisp/net/shr.el
@@ -208,7 +208,8 @@ (defun shr-insert-document (dom)
 	(shr-depth 0)
 	(shr-warning nil)
 	(shr-internal-width (or shr-width (1- (window-width)))))
-    (shr-descend dom)
+    (with-temp-message "Rendering HTML..."
+      (shr-descend dom))
     (shr-remove-trailing-whitespace start (point))
     (when shr-warning
       (message "%s" shr-warning))))


-- 
Nicolas





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-02-05 11:42 ` Nicolas Richard
@ 2015-02-05 16:14   ` Eli Zaretskii
  0 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2015-02-05 16:14 UTC (permalink / raw)
  To: Nicolas Richard; +Cc: rms, 19776

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Thu, 05 Feb 2015 12:42:21 +0100
> Cc: 19776@debbugs.gnu.org
> 
> modified   lisp/net/shr.el
> @@ -208,7 +208,8 @@ (defun shr-insert-document (dom)
>  	(shr-depth 0)
>  	(shr-warning nil)
>  	(shr-internal-width (or shr-width (1- (window-width)))))
> -    (shr-descend dom)
> +    (with-temp-message "Rendering HTML..."
> +      (shr-descend dom))
>      (shr-remove-trailing-whitespace start (point))
>      (when shr-warning
>        (message "%s" shr-warning))))
> 

I'm not sure it's right for a library to display such messages.  I
think the application (in this case, Rmail) should do that.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-02-04 23:03 bug#19776: 25.0.50; HTML rendering is very slow Richard Stallman
  2015-02-05 11:42 ` Nicolas Richard
@ 2015-12-25 22:34 ` Lars Ingebrigtsen
  2015-12-26  6:14   ` Richard Stallman
  2021-10-27 12:59 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-25 22:34 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 19776

Richard Stallman <rms@gnu.org> writes:

> The automatic HTML rendering of the following message takes several
> seconds on this X60 which for most things is blindingly fast.
> Since there is no indication on the screen of what is happening,
> I think that I failed to type a command, and type it again.

It takes a quarter second on my laptop now.  Is this still slow for you?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-12-25 22:34 ` Lars Ingebrigtsen
@ 2015-12-26  6:14   ` Richard Stallman
  2018-04-15 21:49     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Richard Stallman @ 2015-12-26  6:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 19776

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The automatic HTML rendering of the following message takes several
  > > seconds on this X60 which for most things is blindingly fast.
  > > Since there is no indication on the screen of what is happening,
  > > I think that I failed to type a command, and type it again.

  > It takes a quarter second on my laptop now.  Is this still slow for you?

It takes around 5 seconds now -- still enough to lead a user
to think it is broken.  If it is going to take this long,
it should show echo area messages about process.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-12-26  6:14   ` Richard Stallman
@ 2018-04-15 21:49     ` Lars Ingebrigtsen
  2018-04-15 22:00       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-15 21:49 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 19776

Richard Stallman <rms@gnu.org> writes:

> It takes around 5 seconds now -- still enough to lead a user
> to think it is broken.  If it is going to take this long,
> it should show echo area messages about process.

If we had a form like

(with-delayed-message (1 "Rendering html...")
  ... all the code ...)

then we'd be able to display a message if the code took longer than 1
second.  We don't have that, do we?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2018-04-15 21:49     ` Lars Ingebrigtsen
@ 2018-04-15 22:00       ` Lars Ingebrigtsen
  2021-10-22 23:59         ` Stefan Kangas
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-15 22:00 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 19776

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> It takes around 5 seconds now -- still enough to lead a user
>> to think it is broken.  If it is going to take this long,
>> it should show echo area messages about process.
>
> If we had a form like
>
> (with-delayed-message (1 "Rendering html...")
>   ... all the code ...)
>
> then we'd be able to display a message if the code took longer than 1
> second.  We don't have that, do we?

Oh, I asked this before, and the answer is "nope, not at all".

The problem is that it can't be done with normal timers, since "all the
code" may be pure Elisp and never yield.  For that reason, it can't be
done with the new thread support, either.

So it would require some C-level magic.  

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2018-04-15 22:00       ` Lars Ingebrigtsen
@ 2021-10-22 23:59         ` Stefan Kangas
  2021-10-23  7:27           ` Eli Zaretskii
  2021-10-25  2:17           ` Richard Stallman
  0 siblings, 2 replies; 90+ messages in thread
From: Stefan Kangas @ 2021-10-22 23:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Richard Stallman, 19776

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> It takes around 5 seconds now -- still enough to lead a user
>>> to think it is broken.  If it is going to take this long,
>>> it should show echo area messages about process.
>>
>> If we had a form like
>>
>> (with-delayed-message (1 "Rendering html...")
>>   ... all the code ...)
>>
>> then we'd be able to display a message if the code took longer than 1
>> second.  We don't have that, do we?
>
> Oh, I asked this before, and the answer is "nope, not at all".
>
> The problem is that it can't be done with normal timers, since "all the
> code" may be pure Elisp and never yield.  For that reason, it can't be
> done with the new thread support, either.
>
> So it would require some C-level magic.

I guess we can't do this for the C-level DEFUN's (without massive
changes), but we might be able to check some timer before executing a
Lisp function or something.  However, wouldn't such a new check risk
slowing Emacs down as a whole?

IOW, I ask if what you ask for is a little bit "too nice", and if we
shouldn't just fix the problematic ELisp code itself to use a progress
reporter or something to that effect.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-22 23:59         ` Stefan Kangas
@ 2021-10-23  7:27           ` Eli Zaretskii
  2021-10-24 12:43             ` Lars Ingebrigtsen
  2021-10-25  2:17           ` Richard Stallman
  1 sibling, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-23  7:27 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: larsi, rms, 19776

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 22 Oct 2021 16:59:55 -0700
> Cc: Richard Stallman <rms@gnu.org>, 19776@debbugs.gnu.org
> 
> >> then we'd be able to display a message if the code took longer than 1
> >> second.  We don't have that, do we?
> >
> > Oh, I asked this before, and the answer is "nope, not at all".
> >
> > The problem is that it can't be done with normal timers, since "all the
> > code" may be pure Elisp and never yield.  For that reason, it can't be
> > done with the new thread support, either.
> >
> > So it would require some C-level magic.
> 
> I guess we can't do this for the C-level DEFUN's (without massive
> changes), but we might be able to check some timer before executing a
> Lisp function or something.  However, wouldn't such a new check risk
> slowing Emacs down as a whole?

Did someone consider using atimers for this purpose?  See atimer.c.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-23  7:27           ` Eli Zaretskii
@ 2021-10-24 12:43             ` Lars Ingebrigtsen
  2021-10-24 14:04               ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 12:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Kangas, rms, 19776

Eli Zaretskii <eliz@gnu.org> writes:

> Did someone consider using atimers for this purpose?  See atimer.c.

Oh, that looks promising.  I guess we can't run Lisp code from an
atimer?  But then again, we wouldn't need to -- with a thing like

(with-delayed-message 2 "Rendering HTML..."
  (do-the-hthml-rendering))

the message would be precomposed, so we'd just need to display it in the
echo area?

I guess with-delayed-message would have to be implemented in C, since
the atimers aren't exposed from Lisp, but it should be pretty trivial
anyway.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 12:43             ` Lars Ingebrigtsen
@ 2021-10-24 14:04               ` Eli Zaretskii
  2021-10-24 14:25                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-24 14:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, rms, 19776

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  rms@gnu.org,  19776@debbugs.gnu.org
> Date: Sun, 24 Oct 2021 14:43:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Did someone consider using atimers for this purpose?  See atimer.c.
> 
> Oh, that looks promising.  I guess we can't run Lisp code from an
> atimer?  But then again, we wouldn't need to -- with a thing like
> 
> (with-delayed-message 2 "Rendering HTML..."
>   (do-the-hthml-rendering))
> 
> the message would be precomposed, so we'd just need to display it in the
> echo area?

Yes.  And Fmessage is implemented in C anyway.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 14:04               ` Eli Zaretskii
@ 2021-10-24 14:25                 ` Lars Ingebrigtsen
  2021-10-24 16:22                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 14:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, rms, 19776

Eli Zaretskii <eliz@gnu.org> writes:

>> (with-delayed-message 2 "Rendering HTML..."
>>   (do-the-hthml-rendering))
>> 
>> the message would be precomposed, so we'd just need to display it in the
>> echo area?
>
> Yes.  And Fmessage is implemented in C anyway.

Right.  I was more thinking of whether to evaluate the text form first
or when displaying it.  I.e., 

  (with-delayed-message 2 (format "This is taking a long time, %s" (user-full-name))
    ...

so this form will have to evaluate that immediately (before starting the
body), but display the results when the atimer runs out.

I'll have a crack at implementing this and see how it goes...

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 14:25                 ` Lars Ingebrigtsen
@ 2021-10-24 16:22                   ` Lars Ingebrigtsen
  2021-10-24 17:06                     ` Eli Zaretskii
  2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 16:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, rms, 19776

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'll have a crack at implementing this and see how it goes...

I've now implemented the special form, and it works fine interpreted.
But I'm having problems with the byte compilation.

So I've done a

(byte-defop-compiler-1 with-delayed-message)

and I think I understand that it wants to

  (byte-compile-form (nth 1 form))
  (byte-compile-form (nth 2 form))
  (byte-compile-body-do-effect (cdr (cdr (cdr form))))

But this would be the first special form that doesn't have a byte op
code, probably?  Is that allowed?  I couldn't find any other examples of
that being a thing.

I may well be missing something.

But if that's the case, and we don't want to use a byte op for this,
then we'd have to make the special form into a normal macro, and then
create two helper functions (to start and stop the atimer in
question)...  which is perhaps others have done kinda similar things
this way before.

But that's kinda meh.  Am I missing something, and it's easy to write
the byte-compile-with-delayed-message function without a byte op?  Or
should we use a byte op?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 16:22                   ` Lars Ingebrigtsen
@ 2021-10-24 17:06                     ` Eli Zaretskii
  2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-24 17:06 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Stefan Monnier; +Cc: rms, 19776

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  rms@gnu.org,  19776@debbugs.gnu.org
> Date: Sun, 24 Oct 2021 18:22:27 +0200
> 
> I've now implemented the special form, and it works fine interpreted.
> But I'm having problems with the byte compilation.
> 
> So I've done a
> 
> (byte-defop-compiler-1 with-delayed-message)
> 
> and I think I understand that it wants to
> 
>   (byte-compile-form (nth 1 form))
>   (byte-compile-form (nth 2 form))
>   (byte-compile-body-do-effect (cdr (cdr (cdr form))))
> 
> But this would be the first special form that doesn't have a byte op
> code, probably?  Is that allowed?  I couldn't find any other examples of
> that being a thing.
> 
> I may well be missing something.
> 
> But if that's the case, and we don't want to use a byte op for this,
> then we'd have to make the special form into a normal macro, and then
> create two helper functions (to start and stop the atimer in
> question)...  which is perhaps others have done kinda similar things
> this way before.
> 
> But that's kinda meh.  Am I missing something, and it's easy to write
> the byte-compile-with-delayed-message function without a byte op?  Or
> should we use a byte op?

Stefan, any words of wisdom here?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 16:22                   ` Lars Ingebrigtsen
  2021-10-24 17:06                     ` Eli Zaretskii
@ 2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-10-24 18:45                       ` Lars Ingebrigtsen
  2021-10-24 19:10                       ` Lars Ingebrigtsen
  1 sibling, 2 replies; 90+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-24 17:56 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, stefan, rms, 19776

> But this would be the first special form that doesn't have a byte op
> code, probably?  Is that allowed?  I couldn't find any other examples of
> that being a thing.

You don't need a new byte-code, but I'd strongly advise against using
a new special form.  It'll be much simpler to define it as a macro +
a function, where the macro turns

    (with-delayed-message MSG BODY)

into

    (funcall-with-delayed-message MSG (lambda () BODY))


-- Stefan






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-10-24 18:45                       ` Lars Ingebrigtsen
  2021-10-24 19:10                       ` Lars Ingebrigtsen
  1 sibling, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 18:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: stefan, rms, 19776

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You don't need a new byte-code, but I'd strongly advise against using
> a new special form.  It'll be much simpler to define it as a macro +
> a function, where the macro turns
>
>     (with-delayed-message MSG BODY)
>
> into
>
>     (funcall-with-delayed-message MSG (lambda () BODY))

Ah, yes indeed.  That'll simplify things enormously; thanks.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-10-24 18:45                       ` Lars Ingebrigtsen
@ 2021-10-24 19:10                       ` Lars Ingebrigtsen
  2021-10-24 19:18                         ` Lars Ingebrigtsen
  2021-10-24 19:24                         ` Eli Zaretskii
  1 sibling, 2 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 19:10 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: stefan, rms, 19776

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You don't need a new byte-code, but I'd strongly advise against using
> a new special form.  It'll be much simpler to define it as a macro +
> a function, where the macro turns
>
>     (with-delayed-message MSG BODY)
>
> into
>
>     (funcall-with-delayed-message MSG (lambda () BODY))

I've now implemented this...  but testing this with a busy loop shows
that the atimer doesn't fire (or at least that the callback doesn't get
called) in all situations.

If I move the mouse pointer, for instance, then it's called.  If I don't
do anything, and eval this:

(with-delayed-message 0.5 "Yes"
  (dotimes (i 1000000000)
    (+ i 2)))

the atimer callback isn't called.  Anybody know what's up with that?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 19:10                       ` Lars Ingebrigtsen
@ 2021-10-24 19:18                         ` Lars Ingebrigtsen
  2021-10-24 19:24                         ` Eli Zaretskii
  1 sibling, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 19:18 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: stefan, rms, 19776

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If I move the mouse pointer, for instance, then it's called. 

(If I hit the keyboard, it's called, too, so the input system seems to
be causing the atimers to be triggered?)

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 19:10                       ` Lars Ingebrigtsen
  2021-10-24 19:18                         ` Lars Ingebrigtsen
@ 2021-10-24 19:24                         ` Eli Zaretskii
  2021-10-24 19:42                           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-24 19:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  rms@gnu.org,
>   19776@debbugs.gnu.org
> Date: Sun, 24 Oct 2021 21:10:57 +0200
> 
> I've now implemented this...  but testing this with a busy loop shows
> that the atimer doesn't fire (or at least that the callback doesn't get
> called) in all situations.
> 
> If I move the mouse pointer, for instance, then it's called.  If I don't
> do anything, and eval this:
> 
> (with-delayed-message 0.5 "Yes"
>   (dotimes (i 1000000000)
>     (+ i 2)))
> 
> the atimer callback isn't called.  Anybody know what's up with that?

When the timer expires, it delivers a signal, but the signal handler
only sets a flag.  The flag is checked when we call maybe_quit, which
calls do_pending_atimers.  So a Lisp program that hogs the CPU, and
never calls any function that calls maybe_quit, will indeed block
atimers.  However, this is rare for real-life Lisp programs, because
several core primitives call maybe_quit from time to time.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 19:24                         ` Eli Zaretskii
@ 2021-10-24 19:42                           ` Lars Ingebrigtsen
  2021-10-24 20:09                             ` Lars Ingebrigtsen
  2021-10-24 22:14                             ` bug#19776: 25.0.50; HTML rendering is very slow Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 19:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Eli Zaretskii <eliz@gnu.org> writes:

> When the timer expires, it delivers a signal, but the signal handler
> only sets a flag.  The flag is checked when we call maybe_quit, which
> calls do_pending_atimers.  So a Lisp program that hogs the CPU, and
> never calls any function that calls maybe_quit, will indeed block
> atimers.  However, this is rare for real-life Lisp programs, because
> several core primitives call maybe_quit from time to time.

The use case here was for CPU-hogging Lisp code, though, like
`shr-insert-document'.  And it doesn't seem to hit any maybe_quits in
this very synthetic test:

(with-delayed-message 0.5 "Yes"
  (dotimes (i 1000000)
    (with-temp-buffer
      (shr-insert-document
       '(html nil
	      (body nil
		    (table nil
			   (tr nil
			       (td nil "Here's a line ")
			       (td nil "Here's a line ")))))))))
      
Could `with-delayed-message' set a flag that would call maybe_quit more
often, somehow?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 19:42                           ` Lars Ingebrigtsen
@ 2021-10-24 20:09                             ` Lars Ingebrigtsen
  2021-10-24 20:14                               ` Lars Ingebrigtsen
  2021-10-24 22:14                             ` bug#19776: 25.0.50; HTML rendering is very slow Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 20:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Could `with-delayed-message' set a flag that would call maybe_quit more
> often, somehow?

Or...  call do_pending_atimers in our loop somewhere strategic.  It's
just a check for whether the atimers variable is NULL or not, so it
should be reasonably fast.  Or just test the variable directly, for that
matter.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 20:09                             ` Lars Ingebrigtsen
@ 2021-10-24 20:14                               ` Lars Ingebrigtsen
  2021-10-24 20:18                                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 20:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Or...  call do_pending_atimers in our loop somewhere strategic.  It's
> just a check for whether the atimers variable is NULL or not, so it
> should be reasonably fast.  Or just test the variable directly, for that
> matter.

Or...  is something else going on here?

I put in an explicit `while' here, because

DEFUN ("while", Fwhile, Swhile, 1, UNEVALLED, 0,
[...]
  while (!NILP (eval_sub (test)))
    {
      maybe_quit ();
      prog_ignore (body);
    }

So we're calling maybe_quit here:

(with-delayed-message 0.5 "Yes"
  (dotimes (i 1000000)
    (let ((j 0))
      (while (< j 1000)
	(setq j (1+ j))))))

Still, it's not triggered.  Hm.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 20:14                               ` Lars Ingebrigtsen
@ 2021-10-24 20:18                                 ` Lars Ingebrigtsen
  2021-10-24 20:40                                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 20:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Still, it's not triggered.  Hm.

Adding this to maybe_quit:

+  do_pending_atimers ();

Makes the thing work.  I.e.,:

void
maybe_quit (void)
{
  if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))
    process_quit_flag ();
  else if (pending_signals)
    process_pending_signals ();
  do_pending_atimers ();
}

So the atimer code isn't setting pending_signals, so it's never handled
until we get a signal of a different kind.  That has to be a bug, I
think?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 20:18                                 ` Lars Ingebrigtsen
@ 2021-10-24 20:40                                   ` Lars Ingebrigtsen
  2021-10-24 21:52                                     ` Stefan Kangas
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 20:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So the atimer code isn't setting pending_signals, so it's never handled
> until we get a signal of a different kind.  That has to be a bug, I
> think?

I misread the code -- I thought the cunningly named atimers global
variable was the ones that had fired, but it's all the atimers.  So
run_timers just goes through that list and does all the callbacks.

But we wait to check that until we have a pending signal, which doesn't
make much sense, but it's probably that way because there's no other
obvious way to run it "once in a while" without running current_timespec
all the time?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 20:40                                   ` Lars Ingebrigtsen
@ 2021-10-24 21:52                                     ` Stefan Kangas
  2021-10-25 13:08                                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Stefan Kangas @ 2021-10-24 21:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I misread the code -- I thought the cunningly named atimers global
> variable was the ones that had fired, but it's all the atimers.  So
> run_timers just goes through that list and does all the callbacks.

I lost track of this discussion, but the feature itself looks very
promising.

I didn't study what you did here, but one thing that would be really
nice is if we could update this message dynamically.  Other software
show a spinning marker for example, perhaps we could do something
similar?  In the simplest case, you just need to update a character
every 0.1 seconds (or something) in the sequence "|/-\".

I'm not an expert on UIX by any means, but AFAIK, users like it when
there is some visible feedback that the program didn't just go and die.
Research shows that the brain is easy to trick that way; even just a
dumb little spinning thing makes people subjectively feel that the
program is more responsive.  Maybe we could use that to our advantage.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 19:42                           ` Lars Ingebrigtsen
  2021-10-24 20:09                             ` Lars Ingebrigtsen
@ 2021-10-24 22:14                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-10-24 22:28                               ` Lars Ingebrigtsen
  1 sibling, 1 reply; 90+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-24 22:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, stefan, rms, 19776

Lars Ingebrigtsen [2021-10-24 21:42:24] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> When the timer expires, it delivers a signal, but the signal handler
>> only sets a flag.  The flag is checked when we call maybe_quit, which
>> calls do_pending_atimers.  So a Lisp program that hogs the CPU, and
>> never calls any function that calls maybe_quit, will indeed block
>> atimers.  However, this is rare for real-life Lisp programs, because
>> several core primitives call maybe_quit from time to time.
>
> The use case here was for CPU-hogging Lisp code, though, like
> `shr-insert-document'.  And it doesn't seem to hit any maybe_quits in
> this very synthetic test:

Basically all loops should call `maybe_quit`, so the issue is probably
not that `maybe_quit` is not called often enough, but that for some
reason we don't set the vars that it checks or something like that.


        Stefan






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 22:14                             ` bug#19776: 25.0.50; HTML rendering is very slow Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-10-24 22:28                               ` Lars Ingebrigtsen
  2021-10-25  7:33                                 ` Andreas Schwab
                                                   ` (2 more replies)
  0 siblings, 3 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-24 22:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: stefan, rms, 19776

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Basically all loops should call `maybe_quit`, so the issue is probably
> not that `maybe_quit` is not called often enough, but that for some
> reason we don't set the vars that it checks or something like that.

I've been trying to follow the logic in how the atimer stuff is supposed
to work.  It registers a special timer fd that sets a timeout, and it's
supposed to be called back in timerfd_callback.  And that happens if I'm
(for instance) idling in a `sleep-for'.

When Emacs is busy looping, we never get a callback -- presumably
because we're not reading any file descriptors in that case?  But...
was the idea that this would work in a busy Emacs?  I mean, events from
the keyboard/mouse are able to poke Emacs in a way that it realises that
it has a pending event to handle, but not the timerfd?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-22 23:59         ` Stefan Kangas
  2021-10-23  7:27           ` Eli Zaretskii
@ 2021-10-25  2:17           ` Richard Stallman
  2021-10-25 13:10             ` Lars Ingebrigtsen
  1 sibling, 1 reply; 90+ messages in thread
From: Richard Stallman @ 2021-10-25  2:17 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: larsi, 19776

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > IOW, I ask if what you ask for is a little bit "too nice", and if we
  > shouldn't just fix the problematic ELisp code itself to use a progress
  > reporter or something to that effect.

How much slower would it get if it counts the number of lines to be
indented, first thing, and decides based on that whether to give
progress messages?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)







^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 22:28                               ` Lars Ingebrigtsen
@ 2021-10-25  7:33                                 ` Andreas Schwab
  2021-10-25 13:11                                   ` Lars Ingebrigtsen
  2021-10-25 14:00                                 ` Eli Zaretskii
  2021-10-25 16:09                                 ` bug#19776: 25.0.50; HTML rendering is very slow Eli Zaretskii
  2 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25  7:33 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, Stefan Monnier

On Okt 25 2021, Lars Ingebrigtsen wrote:

> When Emacs is busy looping, we never get a callback -- presumably
> because we're not reading any file descriptors in that case?  But...
> was the idea that this would work in a busy Emacs?  I mean, events from
> the keyboard/mouse are able to poke Emacs in a way that it realises that
> it has a pending event to handle, but not the timerfd?

maybe_quit does call process_pending_signals, so this should work the
same way as quit.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 21:52                                     ` Stefan Kangas
@ 2021-10-25 13:08                                       ` Lars Ingebrigtsen
  2021-10-25 13:20                                         ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 13:08 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 19776, rms, monnier

Stefan Kangas <stefan@marxist.se> writes:

> I didn't study what you did here, but one thing that would be really
> nice is if we could update this message dynamically.  Other software
> show a spinning marker for example, perhaps we could do something
> similar?  In the simplest case, you just need to update a character
> every 0.1 seconds (or something) in the sequence "|/-\".
>
> I'm not an expert on UIX by any means, but AFAIK, users like it when
> there is some visible feedback that the program didn't just go and die.
> Research shows that the brain is easy to trick that way; even just a
> dumb little spinning thing makes people subjectively feel that the
> program is more responsive.  Maybe we could use that to our advantage.

These days, you usually get a spinning thing from the OS when the
application is unresponsive in this way, I guess?

But, yes, this mechanism could easily be extended to display a spinner.  

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25  2:17           ` Richard Stallman
@ 2021-10-25 13:10             ` Lars Ingebrigtsen
  0 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 13:10 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Stefan Kangas, 19776

Richard Stallman <rms@gnu.org> writes:

> How much slower would it get if it counts the number of lines to be
> indented, first thing, and decides based on that whether to give
> progress messages?

The issue isn't the number of lines, and it has nothing to do with
indentation -- it's about the complexity of the layout and how easy it
is to make it fit into the buffer.  So making a guess at whether a given
HTML document will take a long or short time to render isn't trivial.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25  7:33                                 ` Andreas Schwab
@ 2021-10-25 13:11                                   ` Lars Ingebrigtsen
  2021-10-25 13:33                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 13:11 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Andreas Schwab <schwab@linux-m68k.org> writes:

>> When Emacs is busy looping, we never get a callback -- presumably
>> because we're not reading any file descriptors in that case?  But...
>> was the idea that this would work in a busy Emacs?  I mean, events from
>> the keyboard/mouse are able to poke Emacs in a way that it realises that
>> it has a pending event to handle, but not the timerfd?
>
> maybe_quit does call process_pending_signals, so this should work the
> same way as quit.

But how do we make Emacs respond to timerfd events the same as quit?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:08                                       ` Lars Ingebrigtsen
@ 2021-10-25 13:20                                         ` Eli Zaretskii
  2021-10-25 13:33                                           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 13:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  19776@debbugs.gnu.org,  rms@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Mon, 25 Oct 2021 15:08:48 +0200
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
> > I didn't study what you did here, but one thing that would be really
> > nice is if we could update this message dynamically.  Other software
> > show a spinning marker for example, perhaps we could do something
> > similar?  In the simplest case, you just need to update a character
> > every 0.1 seconds (or something) in the sequence "|/-\".
> >
> > I'm not an expert on UIX by any means, but AFAIK, users like it when
> > there is some visible feedback that the program didn't just go and die.
> > Research shows that the brain is easy to trick that way; even just a
> > dumb little spinning thing makes people subjectively feel that the
> > program is more responsive.  Maybe we could use that to our advantage.
> 
> These days, you usually get a spinning thing from the OS when the
> application is unresponsive in this way, I guess?
> 
> But, yes, this mechanism could easily be extended to display a spinner.  

??? We already have it: see hourglass pointer.  And it does use
atimers.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:11                                   ` Lars Ingebrigtsen
@ 2021-10-25 13:33                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-10-25 13:46                                       ` Andreas Schwab
  0 siblings, 1 reply; 90+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-25 13:33 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, Andreas Schwab, rms, 19776

Lars Ingebrigtsen [2021-10-25 15:11:03] wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> When Emacs is busy looping, we never get a callback -- presumably
>>> because we're not reading any file descriptors in that case?  But...
>>> was the idea that this would work in a busy Emacs?  I mean, events from
>>> the keyboard/mouse are able to poke Emacs in a way that it realises that
>>> it has a pending event to handle, but not the timerfd?
>>
>> maybe_quit does call process_pending_signals, so this should work the
>> same way as quit.
>
> But how do we make Emacs respond to timerfd events the same as quit?

Can't it give a SIGIO?


        Stefan






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:20                                         ` Eli Zaretskii
@ 2021-10-25 13:33                                           ` Lars Ingebrigtsen
  2021-10-29 17:28                                             ` Stefan Kangas
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 13:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Eli Zaretskii <eliz@gnu.org> writes:

> ??? We already have it: see hourglass pointer.  And it does use
> atimers.

Oh, the spinner thing that's displayed when Emacs is busy is a thing we
do ourselves?  I was so used to none of the things Emacs does with the
mouse pointer not working under Gnome (like setting the colours) that I
assumed that it was a thing the window manager (or Gnome did).

So we don't need to extend this to make a spinner on graphical systems,
at least.

And the hourglass spinner has the same issue I've been dealing with
here: It's not triggered until you give Emacs an input even (either from
the mouse of the keyboard).

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:33                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-10-25 13:46                                       ` Andreas Schwab
  2021-10-25 13:52                                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25 13:46 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Lars Ingebrigtsen, stefan, rms, 19776

On Okt 25 2021, Stefan Monnier wrote:

> Lars Ingebrigtsen [2021-10-25 15:11:03] wrote:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>> When Emacs is busy looping, we never get a callback -- presumably
>>>> because we're not reading any file descriptors in that case?  But...
>>>> was the idea that this would work in a busy Emacs?  I mean, events from
>>>> the keyboard/mouse are able to poke Emacs in a way that it realises that
>>>> it has a pending event to handle, but not the timerfd?
>>>
>>> maybe_quit does call process_pending_signals, so this should work the
>>> same way as quit.
>>
>> But how do we make Emacs respond to timerfd events the same as quit?
>
> Can't it give a SIGIO?

atimer already knows to handle SIGALRM for this.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:46                                       ` Andreas Schwab
@ 2021-10-25 13:52                                         ` Lars Ingebrigtsen
  2021-10-25 14:05                                           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 13:52 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Can't it give a SIGIO?
>
> atimer already knows to handle SIGALRM for this.

In my testing, handle_alarm_signal (which should set pending_signals) is
never called. 

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 22:28                               ` Lars Ingebrigtsen
  2021-10-25  7:33                                 ` Andreas Schwab
@ 2021-10-25 14:00                                 ` Eli Zaretskii
  2021-10-25 14:35                                   ` Andreas Schwab
  2021-10-25 16:09                                 ` bug#19776: 25.0.50; HTML rendering is very slow Eli Zaretskii
  2 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 14:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  rms@gnu.org,
>   19776@debbugs.gnu.org
> Date: Mon, 25 Oct 2021 00:28:12 +0200
> 
> I've been trying to follow the logic in how the atimer stuff is supposed
> to work.  It registers a special timer fd that sets a timeout, and it's
> supposed to be called back in timerfd_callback.  And that happens if I'm
> (for instance) idling in a `sleep-for'.
> 
> When Emacs is busy looping, we never get a callback -- presumably
> because we're not reading any file descriptors in that case?  But...
> was the idea that this would work in a busy Emacs?  I mean, events from
> the keyboard/mouse are able to poke Emacs in a way that it realises that
> it has a pending event to handle, but not the timerfd?

I didn't yet take a good look at the code, so I may not make sense,
but: if the problem with getting Emacs to check atimers is that it
needs an input event, then does it help to define a one-time timer
in addition to arranging the atimer?  When we have an active timer, we
artificially reduce the timeout for pselect so that it expires before
the expected timer -- maybe that is all that's needed, to cause the
input loop crank one more revolution?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:52                                         ` Lars Ingebrigtsen
@ 2021-10-25 14:05                                           ` Lars Ingebrigtsen
  2021-10-25 14:16                                             ` Eli Zaretskii
                                                               ` (2 more replies)
  0 siblings, 3 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 14:05 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> In my testing, handle_alarm_signal (which should set pending_signals) is
> never called. 

I should have read the code more closely:

void
init_atimer (void)
{
#ifdef HAVE_ITIMERSPEC
# ifdef HAVE_TIMERFD
  /* Until this feature is considered stable, you can ask to not use it.  */
  timerfd = (egetenv ("EMACS_IGNORE_TIMERFD") || have_buggy_timerfd () ? -1 :
	     timerfd_create (CLOCK_REALTIME, TFD_NONBLOCK | TFD_CLOEXEC));
# endif
  if (timerfd < 0)
    {
      struct sigevent sigev;
      sigev.sigev_notify = SIGEV_SIGNAL;

So if we have timerfd, the alarm stuff is not set up.

And...  uhm...

EMACS_IGNORE_TIMERFD=t ./src/emacs 

doesn't disable it, either?  That egetenv call returns NULL even if I
start Emacs like that?  Odd.  Anyway, if I forcibly disable timerfd,
then the atimers work like they're supposed to, and the correct code
paths are triggered at the time they're supposed to.

So the timerfd stuff doesn't actually work.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:05                                           ` Lars Ingebrigtsen
@ 2021-10-25 14:16                                             ` Eli Zaretskii
  2021-10-25 14:25                                               ` Lars Ingebrigtsen
  2021-10-25 14:31                                             ` Andreas Schwab
  2021-10-25 14:32                                             ` Lars Ingebrigtsen
  2 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 14:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: schwab, stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 25 Oct 2021 16:05:01 +0200
> Cc: stefan@marxist.se, 19776@debbugs.gnu.org, rms@gnu.org,
>  Stefan Monnier <monnier@iro.umontreal.ca>
> 
> So the timerfd stuff doesn't actually work.

Do you see timerfd in the set of descriptors passed to thread_select?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:16                                             ` Eli Zaretskii
@ 2021-10-25 14:25                                               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 14:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: schwab, stefan, 19776, rms, monnier

Eli Zaretskii <eliz@gnu.org> writes:

> Do you see timerfd in the set of descriptors passed to thread_select?

I do see events from timerfd, so it's not completely non-working.  It's
just that when nothing is calling `accept-process-output' one way or
another, Emacs doesn't get any events from it.  If we do call
`accept-process-output', timerfd_callback is called.

The reason that the atimers are processed when Emacs gets keyboard input
is that that makes pending_signals set, and that in turn makes
maybe_quit check all the atimers to see if any of them have expired.
But we would have an identical outcome if we had just not set up timerfd
at all in these cases.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:05                                           ` Lars Ingebrigtsen
  2021-10-25 14:16                                             ` Eli Zaretskii
@ 2021-10-25 14:31                                             ` Andreas Schwab
  2021-10-25 14:36                                               ` Lars Ingebrigtsen
  2021-10-25 14:32                                             ` Lars Ingebrigtsen
  2 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25 14:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, Stefan Monnier

On Okt 25 2021, Lars Ingebrigtsen wrote:

> doesn't disable it, either?  That egetenv call returns NULL even if I
> start Emacs like that?

Because process-environment hasn't been set up yet.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:05                                           ` Lars Ingebrigtsen
  2021-10-25 14:16                                             ` Eli Zaretskii
  2021-10-25 14:31                                             ` Andreas Schwab
@ 2021-10-25 14:32                                             ` Lars Ingebrigtsen
  2 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 14:32 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> EMACS_IGNORE_TIMERFD=t ./src/emacs 
>
> doesn't disable it, either?  That egetenv call returns NULL even if I
> start Emacs like that?  Odd. 

So this is a tangent, but this is a repeatable bug.  If I call 

  printf ("fd: %s\n", egetenv ("FOO"));

from init_atimer, it always says (null).  (And "FOO" is defined.)
However, if I call egetenv later, I do get the correct value.

So is there something about (e)getenv that makes it not work during the
(early) startup of Emacs?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:00                                 ` Eli Zaretskii
@ 2021-10-25 14:35                                   ` Andreas Schwab
  2021-10-25 15:05                                     ` bug#19776: timerfd doesn't work when busy-looping Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25 14:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, stefan, 19776, rms, monnier

On Okt 25 2021, Eli Zaretskii wrote:

> I didn't yet take a good look at the code, so I may not make sense,
> but: if the problem with getting Emacs to check atimers is that it
> needs an input event, then does it help to define a one-time timer
> in addition to arranging the atimer?  When we have an active timer, we
> artificially reduce the timeout for pselect so that it expires before
> the expected timer -- maybe that is all that's needed, to cause the
> input loop crank one more revolution?

Since timerfd is one of the descriptors to wait for, it already causes
pselect to return in due time.  But it won't help if pselect is not
called in the first place.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:31                                             ` Andreas Schwab
@ 2021-10-25 14:36                                               ` Lars Ingebrigtsen
  2021-10-25 14:48                                                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 14:36 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Andreas Schwab <schwab@linux-m68k.org> writes:

>> doesn't disable it, either?  That egetenv call returns NULL even if I
>> start Emacs like that?
>
> Because process-environment hasn't been set up yet.

Right.  During Emacs startup, it asks for these four variables before
process-environment has been set up:

No EMACS_IGNORE_TIMERFD
No EMACSDATA
No EMACS_FONT_LOG
No HANGUL_KEYBOARD_TYPE

So that's four more bugs, I guess.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 14:36                                               ` Lars Ingebrigtsen
@ 2021-10-25 14:48                                                 ` Lars Ingebrigtsen
  0 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 14:48 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: stefan, 19776, rms, Stefan Monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No EMACS_IGNORE_TIMERFD
> No EMACSDATA
> No EMACS_FONT_LOG
> No HANGUL_KEYBOARD_TYPE
>
> So that's four more bugs, I guess.

No, just one.  I interpreted the output wrong -- the only thing that's
getenv'd before the environment is EMACS_IGNORE_TIMERFD.

So this patch will fix that:

diff --git a/src/emacs.c b/src/emacs.c
index a24543a586..032b27fcf3 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -1872,7 +1872,6 @@ main (int argc, char **argv)
   init_bignum ();
   init_threads ();
   init_eval ();
-  init_atimer ();
   running_asynch_code = 0;
   init_random ();
 
@@ -2034,6 +2033,9 @@ main (int argc, char **argv)
   if (!will_dump_p ())
     set_initial_environment ();
 
+  /* Has to run after the environment is set up. */
+  init_atimer ();
+
 #ifdef WINDOWSNT
   globals_of_w32 ();
 #ifdef HAVE_W32NOTIFY

I think it's probably safe to push to Emacs 28, but since nobody has
complained about it since 2014 (when this was introduced), I'm pushing
it to master instead.

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





^ permalink raw reply related	[flat|nested] 90+ messages in thread

* bug#19776: timerfd doesn't work when busy-looping
  2021-10-25 14:35                                   ` Andreas Schwab
@ 2021-10-25 15:05                                     ` Lars Ingebrigtsen
  2021-10-25 15:59                                       ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 15:05 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 19776, stefan, Andreas Schwab, monnier, rms

The timerfd stuff was added in

commit 768b24eb0e880c0b39e36fd089905cdca572a758
Author:     Dmitry Antipov <dmantipov@yandex.ru>
AuthorDate: Mon Jul 28 10:28:15 2014 +0400

    On GNU/Linux, use timerfd for asynchronous timers.

so I've added Dmitry to the CCs to get some input.

Dmitry, the issue is that with timerfd, no atimers are delivered when
Emacs is busy-looping, like:

  (with-delayed-message 2 "Yes"
    (while t))

If we disable the timerfd stuff, then the timer will fire after two
seconds.  So I'm wondering whether this used to work when timerfd was
introduced (and this has regressed over the years), or whether it's
always been a design constraint that timerfd events would never be
delivered when Emacs ways busy-looping?

When Emacs is idling (and polling the fds), then the timerfd approach
works well, for instance with:

  (with-delayed-message 2 "Yes"
    (sleep-for 10))

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






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: timerfd doesn't work when busy-looping
  2021-10-25 15:05                                     ` bug#19776: timerfd doesn't work when busy-looping Lars Ingebrigtsen
@ 2021-10-25 15:59                                       ` Eli Zaretskii
  2021-10-25 16:16                                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 15:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 19776, dmantipov, stefan, schwab, monnier, rms

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,
>   19776@debbugs.gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca, Andreas
>  Schwab <schwab@linux-m68k.org>
> Date: Mon, 25 Oct 2021 17:05:10 +0200
> 
> Dmitry, the issue is that with timerfd, no atimers are delivered when
> Emacs is busy-looping, like:
> 
>   (with-delayed-message 2 "Yes"
>     (while t))

Btw, the above signals an error; I need to use

  (with-delayed-message (2 "Yes")
    (while t))

instead, to make it work.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-24 22:28                               ` Lars Ingebrigtsen
  2021-10-25  7:33                                 ` Andreas Schwab
  2021-10-25 14:00                                 ` Eli Zaretskii
@ 2021-10-25 16:09                                 ` Eli Zaretskii
  2021-10-25 16:19                                   ` Lars Ingebrigtsen
  2 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 16:09 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  rms@gnu.org,
>   19776@debbugs.gnu.org
> Date: Mon, 25 Oct 2021 00:28:12 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Basically all loops should call `maybe_quit`, so the issue is probably
> > not that `maybe_quit` is not called often enough, but that for some
> > reason we don't set the vars that it checks or something like that.
> 
> I've been trying to follow the logic in how the atimer stuff is supposed
> to work.  It registers a special timer fd that sets a timeout, and it's
> supposed to be called back in timerfd_callback.  And that happens if I'm
> (for instance) idling in a `sleep-for'.
> 
> When Emacs is busy looping, we never get a callback -- presumably
> because we're not reading any file descriptors in that case?  But...
> was the idea that this would work in a busy Emacs?  I mean, events from
> the keyboard/mouse are able to poke Emacs in a way that it realises that
> it has a pending event to handle, but not the timerfd?

Input events work via SIGIO on X, and SIGIO sets pending_signals, and
then we check the atimers.

I guess this means timerfd is only good for when Emacs is calling
thread_select, i.e. either it's idling or waiting for process output.
So timerfd, if available, should be used together with interval
timers, so that we get SIGALRM when we aren't idle, I guess.  Not
either timerfd or interval timers, but both.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: timerfd doesn't work when busy-looping
  2021-10-25 15:59                                       ` Eli Zaretskii
@ 2021-10-25 16:16                                         ` Lars Ingebrigtsen
  2021-10-25 16:41                                           ` bug#19776: The hourglass Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 16:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 19776, dmantipov, stefan, schwab, monnier, rms

Eli Zaretskii <eliz@gnu.org> writes:

>>   (with-delayed-message 2 "Yes"
>>     (while t))
>
> Btw, the above signals an error; I need to use
>
>   (with-delayed-message (2 "Yes")
>     (while t))
>
> instead, to make it work.

Yes, I changed the syntax half an hour ago.  >"?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 16:09                                 ` bug#19776: 25.0.50; HTML rendering is very slow Eli Zaretskii
@ 2021-10-25 16:19                                   ` Lars Ingebrigtsen
  2021-10-25 16:53                                     ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 16:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 19776, rms, monnier

Eli Zaretskii <eliz@gnu.org> writes:

> I guess this means timerfd is only good for when Emacs is calling
> thread_select, i.e. either it's idling or waiting for process output.
> So timerfd, if available, should be used together with interval
> timers, so that we get SIGALRM when we aren't idle, I guess.  Not
> either timerfd or interval timers, but both.

But does timerfd give us anything extra, then?  If we only use interval
timers, things seems to work fine.  So I wonder what the purpose of
introducing the timerfd stuff was.  Greater efficiency?  

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: The hourglass
  2021-10-25 16:16                                         ` Lars Ingebrigtsen
@ 2021-10-25 16:41                                           ` Lars Ingebrigtsen
  2021-10-25 16:51                                             ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 16:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 19776, dmantipov, stefan, schwab, monnier, rms

When not using the timerfd stuff, the hourglass timer is triggered
correctly even when busy-looping like this:

(while t)

But it's not actually displayed until there's a keyboard/mouse event, or
redisplay is triggered otherwise.  So it's this code:

static void
x_show_hourglass (struct frame *f)
{
[...]
             x->hourglass_window = XCreateWindow
               (dpy, parent, 0, 0, 32000, 32000, 0, 0,
                InputOnly, CopyFromParent, mask, &attrs);
           }

         XMapRaised (dpy, x->hourglass_window);
         XFlush (dpy);
       }
    }
}

If I stick a call to Fredisplay in there, then it'll actually display
the hourglass, but that seems rather heavy-handed.  What's the proper
way to trigger the redisplay here?

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






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: The hourglass
  2021-10-25 16:41                                           ` bug#19776: The hourglass Lars Ingebrigtsen
@ 2021-10-25 16:51                                             ` Eli Zaretskii
  2021-10-25 16:57                                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 16:51 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 19776, dmantipov, stefan, schwab, monnier, rms

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 19776@debbugs.gnu.org,  dmantipov@yandex.ru,  stefan@marxist.se,
>   schwab@linux-m68k.org,  monnier@iro.umontreal.ca,  rms@gnu.org
> Date: Mon, 25 Oct 2021 18:41:10 +0200
> 
> static void
> x_show_hourglass (struct frame *f)
> {
> [...]
>              x->hourglass_window = XCreateWindow
>                (dpy, parent, 0, 0, 32000, 32000, 0, 0,
>                 InputOnly, CopyFromParent, mask, &attrs);
>            }
> 
>          XMapRaised (dpy, x->hourglass_window);
>          XFlush (dpy);
>        }
>     }
> }
> 
> If I stick a call to Fredisplay in there, then it'll actually display
> the hourglass, but that seems rather heavy-handed.  What's the proper
> way to trigger the redisplay here?

Try calling FRAME_MOUSE_UPDATE.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 16:19                                   ` Lars Ingebrigtsen
@ 2021-10-25 16:53                                     ` Eli Zaretskii
  2021-10-25 17:01                                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 16:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Dmitry Antipov; +Cc: stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  stefan@marxist.se,  rms@gnu.org,
>   19776@debbugs.gnu.org
> Date: Mon, 25 Oct 2021 18:19:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I guess this means timerfd is only good for when Emacs is calling
> > thread_select, i.e. either it's idling or waiting for process output.
> > So timerfd, if available, should be used together with interval
> > timers, so that we get SIGALRM when we aren't idle, I guess.  Not
> > either timerfd or interval timers, but both.
> 
> But does timerfd give us anything extra, then?  If we only use interval
> timers, things seems to work fine.  So I wonder what the purpose of
> introducing the timerfd stuff was.  Greater efficiency?  

Not sure.  Maybe more reliability?  Signals can be lost or blocked.  I
hope Dmitry will be able to answer that.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: The hourglass
  2021-10-25 16:51                                             ` Eli Zaretskii
@ 2021-10-25 16:57                                               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 16:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 19776, dmantipov, stefan, schwab, monnier, rms

Eli Zaretskii <eliz@gnu.org> writes:

>> If I stick a call to Fredisplay in there, then it'll actually display
>> the hourglass, but that seems rather heavy-handed.  What's the proper
>> way to trigger the redisplay here?
>
> Try calling FRAME_MOUSE_UPDATE.

Didn't make a difference, unfortunately.

	 redisplay_preserve_echo_area (2);

does the trick...  That function seems to be called from everywhere --
perhaps that's the one to use:

   This is useful in situations where you need to redisplay but no
   user action has occurred, making it inappropriate for the message
   area to be cleared.

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 16:53                                     ` Eli Zaretskii
@ 2021-10-25 17:01                                       ` Lars Ingebrigtsen
  2021-10-25 17:07                                         ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-25 17:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Dmitry Antipov, stefan, 19776, rms, monnier

Eli Zaretskii <eliz@gnu.org> writes:

> Not sure.  Maybe more reliability?  Signals can be lost or blocked.  I
> hope Dmitry will be able to answer that.

Yup.

As a simple test, I tried enabling both timerfd and alarms at the same
time, and I don't see anything breaking.  Which isn't surprising, since
all the alarm handler does is set pending_signals, but it's nice to have
it confirmed.  :-)

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 17:01                                       ` Lars Ingebrigtsen
@ 2021-10-25 17:07                                         ` Eli Zaretskii
  2021-10-25 17:11                                           ` Andreas Schwab
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 17:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: dmantipov, stefan, 19776, rms, monnier

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>,  monnier@iro.umontreal.ca,
>   stefan@marxist.se,  rms@gnu.org,  19776@debbugs.gnu.org
> Date: Mon, 25 Oct 2021 19:01:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not sure.  Maybe more reliability?  Signals can be lost or blocked.  I
> > hope Dmitry will be able to answer that.
> 
> Yup.

Also, if we are stuck in pselect call with a long timeout, we won't
get around to calling maybe_quit or process_pending_signals, right?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 17:07                                         ` Eli Zaretskii
@ 2021-10-25 17:11                                           ` Andreas Schwab
  2021-10-25 17:12                                             ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25 17:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 19776, dmantipov, stefan, monnier, Lars Ingebrigtsen, rms

On Okt 25 2021, Eli Zaretskii wrote:

> Also, if we are stuck in pselect call with a long timeout, we won't
> get around to calling maybe_quit or process_pending_signals, right?

pselect will return as soon as input is available.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 17:11                                           ` Andreas Schwab
@ 2021-10-25 17:12                                             ` Eli Zaretskii
  2021-10-25 17:52                                               ` Andreas Schwab
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 17:12 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 19776, dmantipov, stefan, monnier, larsi, rms

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  dmantipov@yandex.ru,
>   stefan@marxist.se,  19776@debbugs.gnu.org,  rms@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Mon, 25 Oct 2021 19:11:03 +0200
> 
> On Okt 25 2021, Eli Zaretskii wrote:
> 
> > Also, if we are stuck in pselect call with a long timeout, we won't
> > get around to calling maybe_quit or process_pending_signals, right?
> 
> pselect will return as soon as input is available.

I mean without timerfd, and if there's no input.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 17:12                                             ` Eli Zaretskii
@ 2021-10-25 17:52                                               ` Andreas Schwab
  2021-10-25 18:25                                                 ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Andreas Schwab @ 2021-10-25 17:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 19776, dmantipov, stefan, monnier, larsi, rms

On Okt 25 2021, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  dmantipov@yandex.ru,
>>   stefan@marxist.se,  19776@debbugs.gnu.org,  rms@gnu.org,
>>   monnier@iro.umontreal.ca
>> Date: Mon, 25 Oct 2021 19:11:03 +0200
>> 
>> On Okt 25 2021, Eli Zaretskii wrote:
>> 
>> > Also, if we are stuck in pselect call with a long timeout, we won't
>> > get around to calling maybe_quit or process_pending_signals, right?
>> 
>> pselect will return as soon as input is available.
>
> I mean without timerfd, and if there's no input.

A signal also interrupts pselect.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 17:52                                               ` Andreas Schwab
@ 2021-10-25 18:25                                                 ` Eli Zaretskii
  0 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2021-10-25 18:25 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 19776, dmantipov, stefan, monnier, larsi, rms

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: larsi@gnus.org,  dmantipov@yandex.ru,  stefan@marxist.se,
>   19776@debbugs.gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca
> Date: Mon, 25 Oct 2021 19:52:33 +0200
> 
> >> > Also, if we are stuck in pselect call with a long timeout, we won't
> >> > get around to calling maybe_quit or process_pending_signals, right?
> >> 
> >> pselect will return as soon as input is available.
> >
> > I mean without timerfd, and if there's no input.
> 
> A signal also interrupts pselect.

Yes, but my reading of wait_reading_process_output is that in that
case we loop right back and re-enter pselect.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2015-02-04 23:03 bug#19776: 25.0.50; HTML rendering is very slow Richard Stallman
  2015-02-05 11:42 ` Nicolas Richard
  2015-12-25 22:34 ` Lars Ingebrigtsen
@ 2021-10-27 12:59 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-27 12:59 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 19776

eww now gives a message about it working when it's rendering the HTML
(and it takes a long time), so I don't think there's more to be done
here, and I'm closing this bug report finally.

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






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-25 13:33                                           ` Lars Ingebrigtsen
@ 2021-10-29 17:28                                             ` Stefan Kangas
  2021-10-29 17:38                                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Stefan Kangas @ 2021-10-29 17:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: 19776, rms, monnier

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> ??? We already have it: see hourglass pointer.  And it does use
>> atimers.
[...]
> So we don't need to extend this to make a spinner on graphical systems,
> at least.

I was talking about showing something in the actual Emacs window, not
just changing the mouse pointer.  The mouse pointer can change also when
some program has just crashed, so users won't necessarily take this as a
sign that "everything is okay, just give us a minute and we'll be back".





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#19776: 25.0.50; HTML rendering is very slow
  2021-10-29 17:28                                             ` Stefan Kangas
@ 2021-10-29 17:38                                               ` Lars Ingebrigtsen
  2021-10-29 17:59                                                 ` bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window Stefan Kangas
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-29 17:38 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 19776, rms, monnier

Stefan Kangas <stefan@marxist.se> writes:

> I was talking about showing something in the actual Emacs window, not
> just changing the mouse pointer.  The mouse pointer can change also when
> some program has just crashed, so users won't necessarily take this as a
> sign that "everything is okay, just give us a minute and we'll be back".

And there's no hourglass pointer in terminal Emacs (which apparently is
almost as popular as GUI Emacs for some reason), so perhaps it's worth
having a spinning thing somewhere.  In the mode line, for instance.

However, if we want that, perhaps it shouldn't be tied to
with-delayed-message, but work exactly like the hourglass -- i.e., start
spinning whenever Emacs is busy for a while.

I'm not at all sure whether there'd be any negative repercussions to
spinning a glyph in the mode line area (for instance -- what about if
you're running over a slow ssh connection?), but perhaps it's worth
exploring and see how goes?

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2021-10-29 17:38                                               ` Lars Ingebrigtsen
@ 2021-10-29 17:59                                                 ` Stefan Kangas
  2021-10-30 12:40                                                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Stefan Kangas @ 2021-10-29 17:59 UTC (permalink / raw)
  To: 51490; +Cc: Lars Ingebrigtsen

Severity: wishlist

(This is a follow-up to Bug#19776.)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> I was talking about showing something in the actual Emacs window, not
>> just changing the mouse pointer.  The mouse pointer can change also when
>> some program has just crashed, so users won't necessarily take this as a
>> sign that "everything is okay, just give us a minute and we'll be back".
>
> And there's no hourglass pointer in terminal Emacs (which apparently is
> almost as popular as GUI Emacs for some reason), so perhaps it's worth
> having a spinning thing somewhere.  In the mode line, for instance.
>
> However, if we want that, perhaps it shouldn't be tied to
> with-delayed-message, but work exactly like the hourglass -- i.e., start
> spinning whenever Emacs is busy for a while.
>
> I'm not at all sure whether there'd be any negative repercussions to
> spinning a glyph in the mode line area (for instance -- what about if
> you're running over a slow ssh connection?), but perhaps it's worth
> exploring and see how goes?

Let's continue discussing this as a new bug.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2021-10-29 17:59                                                 ` bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window Stefan Kangas
@ 2021-10-30 12:40                                                   ` Lars Ingebrigtsen
  2022-09-19 20:16                                                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-30 12:40 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 51490

Stefan Kangas <stefan@marxist.se> writes:

>> I'm not at all sure whether there'd be any negative repercussions to
>> spinning a glyph in the mode line area (for instance -- what about if
>> you're running over a slow ssh connection?), but perhaps it's worth
>> exploring and see how goes?
>
> Let's continue discussing this as a new bug.

I wonder whether this could be implemented by modifying the glyphs in
the mode line directly instead of going through the entire mode line
machinery (for efficiency).  I was thinking we'd designate (say) the
first (or last) displayed position on the mode line as "the spinner"
(and restore the previous glyph there after finishing spinning, of
course).

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





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2021-10-30 12:40                                                   ` Lars Ingebrigtsen
@ 2022-09-19 20:16                                                     ` Lars Ingebrigtsen
  2022-09-20 11:36                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-19 20:16 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 'Eli Zaretskii', 51490

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>> I'm not at all sure whether there'd be any negative repercussions to
>>> spinning a glyph in the mode line area (for instance -- what about if
>>> you're running over a slow ssh connection?), but perhaps it's worth
>>> exploring and see how goes?
>>
>> Let's continue discussing this as a new bug.
>
> I wonder whether this could be implemented by modifying the glyphs in
> the mode line directly instead of going through the entire mode line
> machinery (for efficiency).  I was thinking we'd designate (say) the
> first (or last) displayed position on the mode line as "the spinner"
> (and restore the previous glyph there after finishing spinning, of
> course).

Eli, does this seem like feasible approach to you?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-19 20:16                                                     ` Lars Ingebrigtsen
@ 2022-09-20 11:36                                                       ` Eli Zaretskii
  2022-09-21 11:06                                                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-20 11:36 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 51490@debbugs.gnu.org, "'Eli Zaretskii'" <eliz@gnu.org>
> Date: Mon, 19 Sep 2022 22:16:48 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >>> I'm not at all sure whether there'd be any negative repercussions to
> >>> spinning a glyph in the mode line area (for instance -- what about if
> >>> you're running over a slow ssh connection?), but perhaps it's worth
> >>> exploring and see how goes?
> >>
> >> Let's continue discussing this as a new bug.
> >
> > I wonder whether this could be implemented by modifying the glyphs in
> > the mode line directly instead of going through the entire mode line
> > machinery (for efficiency).  I was thinking we'd designate (say) the
> > first (or last) displayed position on the mode line as "the spinner"
> > (and restore the previous glyph there after finishing spinning, of
> > course).
> 
> Eli, does this seem like feasible approach to you?

I'm not sure I understand the problem and the proposed solution.  Are
we talking about having a spinning character, like | / - \, in the
mode lines of a window on TTY frames?  If so, what are you trying to
save by "modifying the glyphs directly", and why do you think doing so
will produce some savings, as opposed to just update the mode line
normally?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-20 11:36                                                       ` Eli Zaretskii
@ 2022-09-21 11:06                                                         ` Lars Ingebrigtsen
  2022-09-21 11:49                                                           ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-21 11:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 51490

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I understand the problem and the proposed solution.  Are
> we talking about having a spinning character, like | / - \, in the
> mode lines of a window on TTY frames?

Yes -- but not just on TTY frames, but on GUI frames, too (for those
that want that).

> If so, what are you trying to save by "modifying the glyphs directly",
> and why do you think doing so will produce some savings, as opposed to
> just update the mode line normally?

Because this will be happening from an alarm while Lisp code is running,
and we can't run other Lisp code while that is happening.  So we have to
modify the mode line directly from the C function called by the alarm, I
think?






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 11:06                                                         ` Lars Ingebrigtsen
@ 2022-09-21 11:49                                                           ` Eli Zaretskii
  2022-09-21 12:01                                                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-21 11:49 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  51490@debbugs.gnu.org
> Date: Wed, 21 Sep 2022 13:06:25 +0200
> 
> > If so, what are you trying to save by "modifying the glyphs directly",
> > and why do you think doing so will produce some savings, as opposed to
> > just update the mode line normally?
> 
> Because this will be happening from an alarm while Lisp code is running,
> and we can't run other Lisp code while that is happening.

Mode line is drawn in C, not in Lisp.

And if the problem is that we cannot run the display code, either,
then how would it help to poke the glyph?  It won't be shown on the
glass, because redisplay cannot run.  Right?  Or what am I missing?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 11:49                                                           ` Eli Zaretskii
@ 2022-09-21 12:01                                                             ` Lars Ingebrigtsen
  2022-09-21 12:34                                                               ` Stefan Kangas
  2022-09-21 13:05                                                               ` Eli Zaretskii
  0 siblings, 2 replies; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-21 12:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 51490

Eli Zaretskii <eliz@gnu.org> writes:

> Mode line is drawn in C, not in Lisp.
>
> And if the problem is that we cannot run the display code, either,
> then how would it help to poke the glyph?  It won't be shown on the
> glass, because redisplay cannot run.  Right?  Or what am I missing?

Redisplay can run, but we can't run any Lisp code, and the normal
formatting of a mode line does (potentially) run lots of Lisp code,
doesn't it?






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 12:01                                                             ` Lars Ingebrigtsen
@ 2022-09-21 12:34                                                               ` Stefan Kangas
  2022-09-21 13:08                                                                 ` Eli Zaretskii
  2022-09-21 13:05                                                               ` Eli Zaretskii
  1 sibling, 1 reply; 90+ messages in thread
From: Stefan Kangas @ 2022-09-21 12:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: 51490

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Mode line is drawn in C, not in Lisp.
>>
>> And if the problem is that we cannot run the display code, either,
>> then how would it help to poke the glyph?  It won't be shown on the
>> glass, because redisplay cannot run.  Right?  Or what am I missing?
>
> Redisplay can run, but we can't run any Lisp code, and the normal
> formatting of a mode line does (potentially) run lots of Lisp code,
> doesn't it?

BTW, I think one goal here should be to optionally replace the glyph
with a sequence of images/icons (preferably SVG files).





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 12:01                                                             ` Lars Ingebrigtsen
  2022-09-21 12:34                                                               ` Stefan Kangas
@ 2022-09-21 13:05                                                               ` Eli Zaretskii
  2022-09-21 13:32                                                                 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-21 13:05 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  51490@debbugs.gnu.org
> Date: Wed, 21 Sep 2022 14:01:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Mode line is drawn in C, not in Lisp.
> >
> > And if the problem is that we cannot run the display code, either,
> > then how would it help to poke the glyph?  It won't be shown on the
> > glass, because redisplay cannot run.  Right?  Or what am I missing?
> 
> Redisplay can run, but we can't run any Lisp code, and the normal
> formatting of a mode line does (potentially) run lots of Lisp code,
> doesn't it?

That's true, but if Lisp cannot run, neither can redisplay.  They both
access the internal Emacs state: buffers, variables, etc.  Even to
replace a single glyph, you'd need to access faces, right?

Also, poking a single glyph on a GUI frame is unsafe, because no one
can be sure the new glyph will have the same metrics as the old one.

So I think if we want some kind of feature that displays progress
indicator while Emacs is busy, we'd need to develop it.
hourglass-cursor just raises a flag and does it only once, so it can
run from an atimer.  Anything more complex will probably need another
Lisp thread, and calls to synchronization functions (sit-for,
thread-yield, etc.) from the main thread.  Or something.

Or maybe we can run some async subprocess which will display some
animation?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 12:34                                                               ` Stefan Kangas
@ 2022-09-21 13:08                                                                 ` Eli Zaretskii
  0 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-21 13:08 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: larsi, 51490

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 21 Sep 2022 05:34:51 -0700
> Cc: 51490@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Mode line is drawn in C, not in Lisp.
> >>
> >> And if the problem is that we cannot run the display code, either,
> >> then how would it help to poke the glyph?  It won't be shown on the
> >> glass, because redisplay cannot run.  Right?  Or what am I missing?
> >
> > Redisplay can run, but we can't run any Lisp code, and the normal
> > formatting of a mode line does (potentially) run lots of Lisp code,
> > doesn't it?
> 
> BTW, I think one goal here should be to optionally replace the glyph
> with a sequence of images/icons (preferably SVG files).

These are also (special kinds of) glyphs.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 13:05                                                               ` Eli Zaretskii
@ 2022-09-21 13:32                                                                 ` Lars Ingebrigtsen
  2022-09-21 14:01                                                                   ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-21 13:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 51490

Eli Zaretskii <eliz@gnu.org> writes:

> That's true, but if Lisp cannot run, neither can redisplay.  They both
> access the internal Emacs state: buffers, variables, etc.  Even to
> replace a single glyph, you'd need to access faces, right?

I'm not sure that we have to?  That's why I wondered whether we could
somehow get away with just altering the glyph matrix...

> Also, poking a single glyph on a GUI frame is unsafe, because no one
> can be sure the new glyph will have the same metrics as the old one.

I was thinking way more primitive than that -- just altering the
pixelish data on some level.  I.e., I wouldn't want to display the
characters | \ etc, but instead some pre-calculated pixel data.

But like I said, I'm not sure whether even that is feasible...






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 13:32                                                                 ` Lars Ingebrigtsen
@ 2022-09-21 14:01                                                                   ` Eli Zaretskii
  2022-09-21 16:02                                                                     ` Gregory Heytings
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-21 14:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  51490@debbugs.gnu.org
> Date: Wed, 21 Sep 2022 15:32:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's true, but if Lisp cannot run, neither can redisplay.  They both
> > access the internal Emacs state: buffers, variables, etc.  Even to
> > replace a single glyph, you'd need to access faces, right?
> 
> I'm not sure that we have to?  That's why I wondered whether we could
> somehow get away with just altering the glyph matrix...

We barely get away with that on TTY frames (that's how TTY menus are
implemented).  On GUI frames, I don't think it's feasible, not with
the code we have now.

As for not accessing any Lisp data: do you really believe our users
will let us deprive them of even the minimal customization
capabilities, like determining the face of this indicator and how it
generally looks?  I sincerely doubt that.

> > Also, poking a single glyph on a GUI frame is unsafe, because no one
> > can be sure the new glyph will have the same metrics as the old one.
> 
> I was thinking way more primitive than that -- just altering the
> pixelish data on some level.  I.e., I wouldn't want to display the
> characters | \ etc, but instead some pre-calculated pixel data.

We don't write pixels to the glass, we call GUI APIs to do that.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 14:01                                                                   ` Eli Zaretskii
@ 2022-09-21 16:02                                                                     ` Gregory Heytings
  2022-09-21 16:21                                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Gregory Heytings @ 2022-09-21 16:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, stefan, 51490


>
> We barely get away with that on TTY frames (that's how TTY menus are 
> implemented).  On GUI frames, I don't think it's feasible, not with the 
> code we have now.
>

On GUI frames, can't we do something similar to what we do for fringe 
bitmaps?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 16:02                                                                     ` Gregory Heytings
@ 2022-09-21 16:21                                                                       ` Eli Zaretskii
  2022-09-21 17:11                                                                         ` Gregory Heytings
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-21 16:21 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, stefan, 51490

> Date: Wed, 21 Sep 2022 16:02:12 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, stefan@marxist.se, 
>     51490@debbugs.gnu.org
> 
> On GUI frames, can't we do something similar to what we do for fringe 
> bitmaps?

I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and
they do access faces, text properties, overlays,...  So how would this
solve the problem?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 16:21                                                                       ` Eli Zaretskii
@ 2022-09-21 17:11                                                                         ` Gregory Heytings
  2022-09-22  6:28                                                                           ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Gregory Heytings @ 2022-09-21 17:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 51490


>> On GUI frames, can't we do something similar to what we do for fringe 
>> bitmaps?
>
> I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and they 
> do access faces, text properties, overlays,...  So how would this solve 
> the problem?
>

Aren't they the simplest graphical element drawn by Emacs, a simple 
black-and-white bitmap?  I don't think a "busy" indicator would have to 
access faces, text properties and overlays, it could be a simple (list of) 
black-and-white bitmaps drawn at a fixed position, e.g. on the left of the 
mode line.  The interaction with Lisp would be minimal.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-21 17:11                                                                         ` Gregory Heytings
@ 2022-09-22  6:28                                                                           ` Eli Zaretskii
  2022-09-22 10:54                                                                             ` Lars Ingebrigtsen
  2022-09-22 13:02                                                                             ` Gregory Heytings
  0 siblings, 2 replies; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-22  6:28 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, stefan, 51490

> Date: Wed, 21 Sep 2022 17:11:17 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, stefan@marxist.se, 51490@debbugs.gnu.org
> 
> >> On GUI frames, can't we do something similar to what we do for fringe 
> >> bitmaps?
> >
> > I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and they 
> > do access faces, text properties, overlays,...  So how would this solve 
> > the problem?
> 
> Aren't they the simplest graphical element drawn by Emacs, a simple 
> black-and-white bitmap?

No, they aren't.  They are certainly not black-and-white: they use
faces.

> I don't think a "busy" indicator would have to access faces, text
> properties and overlays, it could be a simple (list of)
> black-and-white bitmaps drawn at a fixed position, e.g. on the left
> of the mode line.

Drawn how?  Bitmaps are images, and drawing images in the text area
means we need to invoke all the machinery of redrawing a certain
screen line, be it on the mode line or elsewhere.  That's how Emacs
draws stuff; we don't have any way of directly poking the glass with
an arbitrary bunch of pixels, at least not one that I know of.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22  6:28                                                                           ` Eli Zaretskii
@ 2022-09-22 10:54                                                                             ` Lars Ingebrigtsen
  2022-09-22 12:33                                                                               ` Eli Zaretskii
  2022-09-22 13:02                                                                             ` Gregory Heytings
  1 sibling, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-22 10:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gregory Heytings, stefan, 51490

Eli Zaretskii <eliz@gnu.org> writes:

>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>> black-and-white bitmap?
>
> No, they aren't.  They are certainly not black-and-white: they use
> faces.

They use faces to get at the colours, but nothing beyond that, I think?






^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 10:54                                                                             ` Lars Ingebrigtsen
@ 2022-09-22 12:33                                                                               ` Eli Zaretskii
  2022-09-22 13:08                                                                                 ` Gregory Heytings
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-22 12:33 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: gregory, stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Gregory Heytings <gregory@heytings.org>,  stefan@marxist.se,
>   51490@debbugs.gnu.org
> Date: Thu, 22 Sep 2022 12:54:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Aren't they the simplest graphical element drawn by Emacs, a simple 
> >> black-and-white bitmap?
> >
> > No, they aren't.  They are certainly not black-and-white: they use
> > faces.
> 
> They use faces to get at the colours, but nothing beyond that, I think?

Yes, only the colors.  But accessing the faces means you cannot do
that while the Lisp machine is doing something.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22  6:28                                                                           ` Eli Zaretskii
  2022-09-22 10:54                                                                             ` Lars Ingebrigtsen
@ 2022-09-22 13:02                                                                             ` Gregory Heytings
  2022-09-22 13:59                                                                               ` Eli Zaretskii
  1 sibling, 1 reply; 90+ messages in thread
From: Gregory Heytings @ 2022-09-22 13:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 51490


>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>> black-and-white bitmap?
>
> No, they aren't.  They are certainly not black-and-white: they use 
> faces.
>

Sorry, I wrote a bit too fast (as usual), I did not mean literally "black" 
and "white", I meant "two colors", represented by a two-value pixel 
bitmap.

>
> Drawn how?  Bitmaps are images, and drawing images in the text area 
> means we need to invoke all the machinery of redrawing a certain screen 
> line, be it on the mode line or elsewhere.  That's how Emacs draws 
> stuff; we don't have any way of directly poking the glass with an 
> arbitrary bunch of pixels, at least not one that I know of.
>

I'm thinking aloud here, sorry if it isn't useful.  But I think we have at 
least one similar occurrence: XTflash.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 12:33                                                                               ` Eli Zaretskii
@ 2022-09-22 13:08                                                                                 ` Gregory Heytings
  2022-09-22 14:03                                                                                   ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Gregory Heytings @ 2022-09-22 13:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, stefan, 51490


>>>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>>>> black-and-white bitmap?
>>>
>>> No, they aren't.  They are certainly not black-and-white: they use 
>>> faces.
>>
>> They use faces to get at the colours, but nothing beyond that, I think?
>
> Yes, only the colors.  But accessing the faces means you cannot do that 
> while the Lisp machine is doing something.
>

But would it be really necessary to access these faces each time the 
indicator would be drawn?  We could for example cache the values of these 
two colors somewhere, or decide to do something different and use a 
specific function to set these two colors without going through the whole 
face machinery, something like (set-busy-indicator-colors FOREGROUND 
BACKGROUND).





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 13:02                                                                             ` Gregory Heytings
@ 2022-09-22 13:59                                                                               ` Eli Zaretskii
  0 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-22 13:59 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, stefan, 51490

> Date: Thu, 22 Sep 2022 13:02:53 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, stefan@marxist.se, 51490@debbugs.gnu.org
> 
> > Drawn how?  Bitmaps are images, and drawing images in the text area 
> > means we need to invoke all the machinery of redrawing a certain screen 
> > line, be it on the mode line or elsewhere.  That's how Emacs draws 
> > stuff; we don't have any way of directly poking the glass with an 
> > arbitrary bunch of pixels, at least not one that I know of.
> 
> I'm thinking aloud here, sorry if it isn't useful.  But I think we have at 
> least one similar occurrence: XTflash.

Which part of it seemed similar to what is being discussed here?





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 13:08                                                                                 ` Gregory Heytings
@ 2022-09-22 14:03                                                                                   ` Eli Zaretskii
  2022-09-22 15:57                                                                                     ` Gregory Heytings
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-22 14:03 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, stefan, 51490

> Date: Thu, 22 Sep 2022 13:08:25 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, stefan@marxist.se, 
>     51490@debbugs.gnu.org
> 
> >> They use faces to get at the colours, but nothing beyond that, I think?
> >
> > Yes, only the colors.  But accessing the faces means you cannot do that 
> > while the Lisp machine is doing something.
> 
> But would it be really necessary to access these faces each time the 
> indicator would be drawn?  We could for example cache the values of these 
> two colors somewhere

Faces are already cached.  But for each cache there comes a time when
it must be flushed and/or refreshed, and during those times you cannot
safely use the cache.

> or decide to do something different and use a 
> specific function to set these two colors without going through the whole 
> face machinery, something like (set-busy-indicator-colors FOREGROUND 
> BACKGROUND).

As soon as we allow set-busy-indicator-colors or somesuch, we have a
problem with Lisp programs doing that exactly when there's time to
redraw the indicator.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 14:03                                                                                   ` Eli Zaretskii
@ 2022-09-22 15:57                                                                                     ` Gregory Heytings
  2022-09-22 16:21                                                                                       ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Gregory Heytings @ 2022-09-22 15:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stefan, 51490


>> I'm thinking aloud here, sorry if it isn't useful.  But I think we have 
>> at least one similar occurrence: XTflash.
>
> Which part of it seemed similar to what is being discussed here?
>

The fact that a portion of the frame is modified without a complete 
redisplay of the frame, through primitive drawing functions?  Am I missing 
something?  Would it not be possible to draw a busy indicator at a fixed 
position of the frame with XDrawRectangle for the background, followed by 
XDrawPoints for the foreground?

>> But would it be really necessary to access these faces each time the 
>> indicator would be drawn?  We could for example cache the values of 
>> these two colors somewhere
>
> Faces are already cached.  But for each cache there comes a time when it 
> must be flushed and/or refreshed, and during those times you cannot 
> safely use the cache.
>

What I had in mind is a more primitive cache mechanism: two C variables.

>> or decide to do something different and use a specific function to set 
>> these two colors without going through the whole face machinery, 
>> something like (set-busy-indicator-colors FOREGROUND BACKGROUND).
>
> As soon as we allow set-busy-indicator-colors or somesuch, we have a 
> problem with Lisp programs doing that exactly when there's time to 
> redraw the indicator.
>

We could specify that set-busy-indicator-colors is only meant to be used 
in init files, for example.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 15:57                                                                                     ` Gregory Heytings
@ 2022-09-22 16:21                                                                                       ` Eli Zaretskii
  2022-09-23 15:06                                                                                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-22 16:21 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, stefan, 51490

> Date: Thu, 22 Sep 2022 15:57:04 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, stefan@marxist.se, 51490@debbugs.gnu.org
> 
> >> I'm thinking aloud here, sorry if it isn't useful.  But I think we have 
> >> at least one similar occurrence: XTflash.
> >
> > Which part of it seemed similar to what is being discussed here?
> 
> The fact that a portion of the frame is modified without a complete 
> redisplay of the frame, through primitive drawing functions?  Am I missing 
> something?  Would it not be possible to draw a busy indicator at a fixed 
> position of the frame with XDrawRectangle for the background, followed by 
> XDrawPoints for the foreground?

It should be possible, yes.  I just said that we don't have such an
infrastructure yet, it needs to be written first.  When someone does
write it, they will have to deal with the issue of what kind of
drawing do we allow there; for example, a 1-pixel line is easy, but is
unlikely to be visually appealing.

And the main problem this will have to solve is this: whatever you
draw behind the back of the display engine will run the risk of being
wiped out when the next redisplay cycle kicks in.  XTflash doesn't
have that problem because it is invoked from Lisp, not from an async
signal handler.

> >> or decide to do something different and use a specific function to set 
> >> these two colors without going through the whole face machinery, 
> >> something like (set-busy-indicator-colors FOREGROUND BACKGROUND).
> >
> > As soon as we allow set-busy-indicator-colors or somesuch, we have a 
> > problem with Lisp programs doing that exactly when there's time to 
> > redraw the indicator.
> 
> We could specify that set-busy-indicator-colors is only meant to be used 
> in init files, for example.

Good luck with getting that past our users!





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-22 16:21                                                                                       ` Eli Zaretskii
@ 2022-09-23 15:06                                                                                         ` Lars Ingebrigtsen
  2022-09-23 15:45                                                                                           ` Eli Zaretskii
  0 siblings, 1 reply; 90+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-23 15:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gregory Heytings, stefan, 51490

Eli Zaretskii <eliz@gnu.org> writes:

> It should be possible, yes.  I just said that we don't have such an
> infrastructure yet, it needs to be written first.  When someone does
> write it, they will have to deal with the issue of what kind of
> drawing do we allow there; for example, a 1-pixel line is easy, but is
> unlikely to be visually appealing.

The spinner will presumably not be done with line drawing, but consist
of a set of 8 glyphs that are defined along the lines of fringe markers.

> And the main problem this will have to solve is this: whatever you
> draw behind the back of the display engine will run the risk of being
> wiped out when the next redisplay cycle kicks in.

Yes, we'd have to have a way to tell the redisplay to lay off redrawing
in that rectangle, probably.





^ permalink raw reply	[flat|nested] 90+ messages in thread

* bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window
  2022-09-23 15:06                                                                                         ` Lars Ingebrigtsen
@ 2022-09-23 15:45                                                                                           ` Eli Zaretskii
  0 siblings, 0 replies; 90+ messages in thread
From: Eli Zaretskii @ 2022-09-23 15:45 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: gregory, stefan, 51490

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Gregory Heytings <gregory@heytings.org>,  stefan@marxist.se,
>   51490@debbugs.gnu.org
> Date: Fri, 23 Sep 2022 17:06:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It should be possible, yes.  I just said that we don't have such an
> > infrastructure yet, it needs to be written first.  When someone does
> > write it, they will have to deal with the issue of what kind of
> > drawing do we allow there; for example, a 1-pixel line is easy, but is
> > unlikely to be visually appealing.
> 
> The spinner will presumably not be done with line drawing, but consist
> of a set of 8 glyphs that are defined along the lines of fringe markers.

Then this gets back to how to do that behind the back of the display
code.  We'd need to invent new machinery for that.

> > And the main problem this will have to solve is this: whatever you
> > draw behind the back of the display engine will run the risk of being
> > wiped out when the next redisplay cycle kicks in.
> 
> Yes, we'd have to have a way to tell the redisplay to lay off redrawing
> in that rectangle, probably.

That's also something that doesn't exist, and will have to be added
somehow.





^ permalink raw reply	[flat|nested] 90+ messages in thread

end of thread, other threads:[~2022-09-23 15:45 UTC | newest]

Thread overview: 90+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-04 23:03 bug#19776: 25.0.50; HTML rendering is very slow Richard Stallman
2015-02-05 11:42 ` Nicolas Richard
2015-02-05 16:14   ` Eli Zaretskii
2015-12-25 22:34 ` Lars Ingebrigtsen
2015-12-26  6:14   ` Richard Stallman
2018-04-15 21:49     ` Lars Ingebrigtsen
2018-04-15 22:00       ` Lars Ingebrigtsen
2021-10-22 23:59         ` Stefan Kangas
2021-10-23  7:27           ` Eli Zaretskii
2021-10-24 12:43             ` Lars Ingebrigtsen
2021-10-24 14:04               ` Eli Zaretskii
2021-10-24 14:25                 ` Lars Ingebrigtsen
2021-10-24 16:22                   ` Lars Ingebrigtsen
2021-10-24 17:06                     ` Eli Zaretskii
2021-10-24 17:56                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-24 18:45                       ` Lars Ingebrigtsen
2021-10-24 19:10                       ` Lars Ingebrigtsen
2021-10-24 19:18                         ` Lars Ingebrigtsen
2021-10-24 19:24                         ` Eli Zaretskii
2021-10-24 19:42                           ` Lars Ingebrigtsen
2021-10-24 20:09                             ` Lars Ingebrigtsen
2021-10-24 20:14                               ` Lars Ingebrigtsen
2021-10-24 20:18                                 ` Lars Ingebrigtsen
2021-10-24 20:40                                   ` Lars Ingebrigtsen
2021-10-24 21:52                                     ` Stefan Kangas
2021-10-25 13:08                                       ` Lars Ingebrigtsen
2021-10-25 13:20                                         ` Eli Zaretskii
2021-10-25 13:33                                           ` Lars Ingebrigtsen
2021-10-29 17:28                                             ` Stefan Kangas
2021-10-29 17:38                                               ` Lars Ingebrigtsen
2021-10-29 17:59                                                 ` bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window Stefan Kangas
2021-10-30 12:40                                                   ` Lars Ingebrigtsen
2022-09-19 20:16                                                     ` Lars Ingebrigtsen
2022-09-20 11:36                                                       ` Eli Zaretskii
2022-09-21 11:06                                                         ` Lars Ingebrigtsen
2022-09-21 11:49                                                           ` Eli Zaretskii
2022-09-21 12:01                                                             ` Lars Ingebrigtsen
2022-09-21 12:34                                                               ` Stefan Kangas
2022-09-21 13:08                                                                 ` Eli Zaretskii
2022-09-21 13:05                                                               ` Eli Zaretskii
2022-09-21 13:32                                                                 ` Lars Ingebrigtsen
2022-09-21 14:01                                                                   ` Eli Zaretskii
2022-09-21 16:02                                                                     ` Gregory Heytings
2022-09-21 16:21                                                                       ` Eli Zaretskii
2022-09-21 17:11                                                                         ` Gregory Heytings
2022-09-22  6:28                                                                           ` Eli Zaretskii
2022-09-22 10:54                                                                             ` Lars Ingebrigtsen
2022-09-22 12:33                                                                               ` Eli Zaretskii
2022-09-22 13:08                                                                                 ` Gregory Heytings
2022-09-22 14:03                                                                                   ` Eli Zaretskii
2022-09-22 15:57                                                                                     ` Gregory Heytings
2022-09-22 16:21                                                                                       ` Eli Zaretskii
2022-09-23 15:06                                                                                         ` Lars Ingebrigtsen
2022-09-23 15:45                                                                                           ` Eli Zaretskii
2022-09-22 13:02                                                                             ` Gregory Heytings
2022-09-22 13:59                                                                               ` Eli Zaretskii
2021-10-24 22:14                             ` bug#19776: 25.0.50; HTML rendering is very slow Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-24 22:28                               ` Lars Ingebrigtsen
2021-10-25  7:33                                 ` Andreas Schwab
2021-10-25 13:11                                   ` Lars Ingebrigtsen
2021-10-25 13:33                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-25 13:46                                       ` Andreas Schwab
2021-10-25 13:52                                         ` Lars Ingebrigtsen
2021-10-25 14:05                                           ` Lars Ingebrigtsen
2021-10-25 14:16                                             ` Eli Zaretskii
2021-10-25 14:25                                               ` Lars Ingebrigtsen
2021-10-25 14:31                                             ` Andreas Schwab
2021-10-25 14:36                                               ` Lars Ingebrigtsen
2021-10-25 14:48                                                 ` Lars Ingebrigtsen
2021-10-25 14:32                                             ` Lars Ingebrigtsen
2021-10-25 14:00                                 ` Eli Zaretskii
2021-10-25 14:35                                   ` Andreas Schwab
2021-10-25 15:05                                     ` bug#19776: timerfd doesn't work when busy-looping Lars Ingebrigtsen
2021-10-25 15:59                                       ` Eli Zaretskii
2021-10-25 16:16                                         ` Lars Ingebrigtsen
2021-10-25 16:41                                           ` bug#19776: The hourglass Lars Ingebrigtsen
2021-10-25 16:51                                             ` Eli Zaretskii
2021-10-25 16:57                                               ` Lars Ingebrigtsen
2021-10-25 16:09                                 ` bug#19776: 25.0.50; HTML rendering is very slow Eli Zaretskii
2021-10-25 16:19                                   ` Lars Ingebrigtsen
2021-10-25 16:53                                     ` Eli Zaretskii
2021-10-25 17:01                                       ` Lars Ingebrigtsen
2021-10-25 17:07                                         ` Eli Zaretskii
2021-10-25 17:11                                           ` Andreas Schwab
2021-10-25 17:12                                             ` Eli Zaretskii
2021-10-25 17:52                                               ` Andreas Schwab
2021-10-25 18:25                                                 ` Eli Zaretskii
2021-10-25  2:17           ` Richard Stallman
2021-10-25 13:10             ` Lars Ingebrigtsen
2021-10-27 12:59 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.