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 11:55:34 +0300 Message-ID: <8361zo6um1.fsf@gnu.org> References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1366016132 11413 80.91.229.3 (15 Apr 2013 08:55:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 08:55:32 +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 10:55:36 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 1URfCJ-0003B0-QC for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 10:55:36 +0200 Original-Received: from localhost ([::1]:53762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URfCJ-0003ts-9A for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 04:55:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URfCD-0003sZ-C1 for emacs-devel@gnu.org; Mon, 15 Apr 2013 04:55:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URfCB-0003R0-Fq for emacs-devel@gnu.org; Mon, 15 Apr 2013 04:55:29 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:64053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URfCB-0003Qi-5Y for emacs-devel@gnu.org; Mon, 15 Apr 2013 04:55:27 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MLA00D00GPSBL00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 15 Apr 2013 11:55:25 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLA00DLNGSC6R60@a-mtaout23.012.net.il>; Mon, 15 Apr 2013 11:55:25 +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.175 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:158917 Archived-At: > Date: Mon, 15 Apr 2013 16:59:31 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org > > >>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii said: > > > I wish that platform-specific display tricks would not abuse > > platform-independent display mechanisms in this way. I mean, making > > the window edges round by triggering expose events as result of > > previous redisplay. Can't this be done in the Mac display back-end > > instead? > > 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. > 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. > > While adding a flag to the glyph matrix looks like a no-brainer at > > first sight, doing so for a benefit of a single platform is > > something that at the very least should be heavily commented > > (including the above sequence). Otherwise, a few years from now, > > when this issue is no longer relevant, how can we even start > > thinking whether this flag is still needed or not? > > 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. > > . what about the same flag of the desired_matrix -- should it be > > cleared explicitly, and if so, where? > > The same question probably applies to the existing `begv' and 'zv' > members of `struct glyph_matrix': they are meaningful/used only for > the current matrix and never cleared. Those members are only tested to see whether the last redisplay cycle ran to completion, and whether the displayed buffer changed behind redisplay's back. A stale value here can at worst cause redundant redisplays. By contrast, the flag you are suggesting, if stale, will cause the cursor be redrawn incorrectly, IIUC. > If someone proposes more appropriate way and/or place to record the > status of the cursor so that the subsequent "expose" handler call can > recover the result of previous redisplay, I would really appreciate > it. I'm still interested to know why this cannot be handled in the Mac specific display back-end code.