From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: make-pointer-invisible on Windows Date: Fri, 26 Jun 2015 11:15:06 +0200 Message-ID: <558D181A.4070402@gmx.at> References: <558A75C6.7040003@gmx.at> <83zj3pdusu.fsf@gnu.org> <558AEB8D.4070603@gmx.at> <83k2usewtv.fsf@gnu.org> <558BA156.6090508@gmx.at> <83a8vnesqm.fsf@gnu.org> <558CF75E.90801@gmx.at> <83wpyqdflh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435310440 9974 80.91.229.3 (26 Jun 2015 09:20:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 09:20:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 26 11:20:32 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z8PoD-0006RY-Rb for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 11:20:29 +0200 Original-Received: from localhost ([::1]:58957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8PoD-0006gh-9g for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 05:20:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Po6-0006Xs-9U for emacs-devel@gnu.org; Fri, 26 Jun 2015 05:20:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8Po5-0003pG-FB for emacs-devel@gnu.org; Fri, 26 Jun 2015 05:20:22 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:60402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Po0-0003fh-Sw; Fri, 26 Jun 2015 05:20:17 -0400 Original-Received: from [194.166.84.48] ([194.166.84.48]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVvDo-1Zb5cf26EC-00X7WL; Fri, 26 Jun 2015 11:15:13 +0200 In-Reply-To: <83wpyqdflh.fsf@gnu.org> X-Provags-ID: V03:K0:uiiGtSKjkPjxdHQZVnS6KAIXLrYWhvpog9UMRke1ADxxGVGVGnh beviU/Mn0VVJhE8fAHEIiYnHhVhf+1cK5qQD6x4L9cxYmhEDjhJZrUbS0P2bi53sUaqKkXK /dZPCM+0CMfxu4xbx5/nAlQZg4afpfh3N8pnwphk8oFbqE5OzfAPN6YJ1/F/BU7AS9K4abw /yxNdbgMZr7wj38NKdJXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:NM4WOIfXl1k=:8DLee0cFr10jOUstShuVxn SxV/TJD8GNoJ9DQ3Rfw3h8G64eyz/CQ4knlL3/CuchhBUAXsElHlbCRwsBMwKPfGbTIQVXBB9 twNfQzpN11M3pDNEoaYtfmUcRZHDm18BVXFxeYjNarYCnrmwZsH+1ZZD2EvYZLw35ogKRyotL AR9M/5d2Y3pM2wOCaT+Tur5AoaDE5TomZaLFqxSBpul1y7ZhffANXqOA34dQA6ynxci5aRIF5 B1q/WeBo8Y6/jDm2fdCl/ScB1F8YQNaBApp5PwZ6g1F2QfaYfx7SOmmw2kUs1rMaczS4P4Ni6 cQnewxdPWs91lSSDZo4JNPcoMrATdl/Mtuvx23OB8wmWApx2V64UjP90DHurCrGeFjag3iCYp QQfFIvtoUtfT91/1fZJHMPWznR/pqynncl2BG5Uyq7yYP9bNgheb0lhIL6FCzN0do8pgVErKT 98D20ruulvsBjTLqK38xcuZ+QQmsAHUybFNlIcoxUquvDiEjPEzaFqFrvHzR1gPUYHfOhuBAq eJlDFA3M8pPck3tQTN9gz/3ssUC6ZZJ78vIgEdK0lBfsY9blgYxNpj+7mO1jaHpT6yDXlH5xr qnk359zdf7DZ+ywbWGjgUTyp9X4qJFba2AgFvc/Bsg5Ggq4rCGhYX8Iw/fcdvndVNAxZk1GSc XA3zyTaf/gsdEdPv8fZfV8yZerl6HKN0oUtxGRr4bHxiuk2XH3MBiRgqkqoHeliGMCj8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187556 Archived-At: > Btw, how does this work on X? When we wait in waitpid for a > subprocess launched via "M-!", we are not supposed to call the > read-socket hook, so the X messages that tell us to redraw portions of > our frames are not supposed to be redrawn. .. not supposed to be processed. > If this is what happens, > then the w32 behavior seems to be consistent; if not, what am I > missing here? Specifically, can you show a backtrace on X from calls > to expose_frame when we are waiting for a synchronous subprocess? That was a misunderstanding. On X the frame is not redrawn either. The difference was that on Windows, when waiting, the mouse cursor remained invisible while on X it became visible again. Your patch fixed that already. I didn't believe you could (reasonably) redraw the frame while waiting for a subprocess, but you somehow sounded optimistic ... martin