From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Mon, 15 Apr 2013 18:48:29 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> <8361zo6um1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366019317 12225 80.91.229.3 (15 Apr 2013 09:48:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 09:48:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 15 11:48:41 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 1URg1g-0000At-L4 for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 11:48:40 +0200 Original-Received: from localhost ([::1]:56965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URg1g-0002L4-B2 for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 05:48:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URg1d-0002Kz-IT for emacs-devel@gnu.org; Mon, 15 Apr 2013 05:48:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URg1c-0006pX-5r for emacs-devel@gnu.org; Mon, 15 Apr 2013 05:48:37 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URg1Z-0006oJ-Fj; Mon, 15 Apr 2013 05:48:33 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id B9F32C055D; Mon, 15 Apr 2013 18:48:29 +0900 (JST) In-Reply-To: <8361zo6um1.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 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:158920 Archived-At: >>>>> On Mon, 15 Apr 2013 11:55:34 +0300, Eli Zaretskii said: >> No, it's not an abuse at all. Invalidating the area that needs to >> be updated and let the "expose" handler draw is a very standard >> (sometimes only) way of drawing even on GTK+. > I was talking specifically about invalidating fractions of screen > lines (a.k.a. "glyph rows"). > I'm still interested to know why this cannot be done entirely in the > display back-end. I'm using the "expose" handler for recovering the display contents through invalidation, because that is really what it is for. 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. >> The similar inconsistency in Emacs display can also happen on other >> platforms in principle, depending on the timing of the "expose" >> event. The only difference is the invalidation happens >> internally/actively or externally/passively. That's why the latter >> is difficult to reproduce. > I suspect that triggering the event internally is the only situation > where this can happen, because it might cause the expose event be > delivered between two successive redisplay cycles that would > normally take care of the change in the value of > cursor_in_echo_area. What about this example? (progn (let ((cursor-in-echo-area t)) (message "foo") (sit-for 0)) (sleep-for 10)) If the "expose" event happen for the echo area during the execution of sleep-for, would the cursor be correctly recovered? >> The reason is simple: the expose handler should recover the >> contents of the previous redisplay with respect to the requested >> rectangle. > And yet we don't see the result on any other platform. 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 insist my patch is correct. But I'd say the current behavior is wrong and the fix should be done in the platform-independent part rather than in the code for a particular platform where the problem happens to easily emerge. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp