From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Mon, 15 Apr 2013 13:57:14 +0300 Message-ID: <8338us6oz9.fsf@gnu.org> References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> <8361zo6um1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1366023430 24135 80.91.229.3 (15 Apr 2013 10:57:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 10:57:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 15 12:57:14 2013 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 1URh62-00053Q-6D for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 12:57:14 +0200 Original-Received: from localhost ([::1]:51854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URh61-0005ut-Sb for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 06:57:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URh5x-0005ui-0S for emacs-devel@gnu.org; Mon, 15 Apr 2013 06:57:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URh5v-0001Xt-4l for emacs-devel@gnu.org; Mon, 15 Apr 2013 06:57:08 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URh5u-0001XN-SU for emacs-devel@gnu.org; Mon, 15 Apr 2013 06:57:07 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MLA00L00MC4I500@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 15 Apr 2013 13:57:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLA00LRCMF44AA0@a-mtaout22.012.net.il>; Mon, 15 Apr 2013 13:57:04 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:158921 Archived-At: > Date: Mon, 15 Apr 2013 18:48:29 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org >=20 > > I'm still interested to know why this cannot be done entirely in = the > > display back-end. >=20 > I'm using the "expose" handler for recovering the display contents > through invalidation, because that is really what it is for. >=20 > On Mac, the "expose" handler is called in many situations than you > might expect including outside the control of application code: e.g= ., > creating a snapshot of the window image for icons or "Expos=E9" > (http://support.apple.com/kb/HT2503). I'm not sure about other > platforms/toolkits, but I wouldn't be surprised if similar things > happen there for providing some fancy features. Nowadays, drawing > outside the "expose" handler is exceptional and subject to several > restrictions. Sorry, I don't understand. I was asking why the code that makes the corners of the window round cannot be run directly from the GUI drawing code of the Mac display back-end, e.g., from the update_end method. Why does it _have_ to be run from the expose handler? > (progn > (let ((cursor-in-echo-area t)) > (message "foo") > (sit-for 0)) > (sleep-for 10)) >=20 > If the "expose" event happen for the echo area during the execution= of > sleep-for, would the cursor be correctly recovered? I cannot make it produce an incorrect cursor, but maybe I don't generate the expose event as you intended. How did you do it? Does the expose event on the Mac interrupt sleep-for? > >> The reason is simple: the expose handler should recover the > >> contents of the previous redisplay with respect to the requested > >> rectangle. >=20 > > And yet we don't see the result on any other platform. >=20 > You don't agree the principle for the "expose" handler above (i.e.,= it > should recover the contents of the previous redisplay)? Then what = is > your expected behavior of the "expose" handler? I don't like the expose event being used for this purpose in the firs= t place. Platform-specific pixel-level drawing shouldn't IMO be expose= d to the device-independent portions of the display engine. And second, I don't think I understand what needs to be recovered except what the glyph matrix describes. The redisplay that happens i= n response to the expose event needs to know where to draw the cursor and how to draw it _at_the_moment_of_redisplay_; why is it important where the cursor was during previous redisplay cycle, if it is no longer there and shouldn't be there? > I don't insist my patch is correct. But I'd say the current behavi= or > is wrong and the fix should be done in the platform-independent par= t > rather than in the code for a particular platform where the problem > happens to easily emerge. I asked you to describe a series of events that could reproduce such = a problem, and your description was about a Mac-specific feature. If this is a platform-independent problem, there should be a way of reproducing it on other platforms as well.