From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
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: <wllijvzf9l.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlmx2m97q0.wl%mituharu@math.s.chiba-u.ac.jp>
	<wltxvon5ph.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlbofojyuv.wl%mituharu@math.s.chiba-u.ac.jp>
	<wl1ufign2m.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlr4mq1t5t.wl%mituharu@math.s.chiba-u.ac.jp>
	<wl38y8uqkf.wl%mituharu@math.s.chiba-u.ac.jp>
	<wl6222dk3a.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlvc96z8n6.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlobeq1u3q.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlip3twhe9.wl%mituharu@math.s.chiba-u.ac.jp>
	<wlehedzkra.wl%mituharu@math.s.chiba-u.ac.jp>
	<83ip3p72mz.fsf@gnu.org>
	<wl38uszgen.wl%mituharu@math.s.chiba-u.ac.jp>
	<83d2tw73h7.fsf@gnu.org>
	<wltxn8kyvw.wl%mituharu@math.s.chiba-u.ac.jp>
	<8361zo6um1.fsf@gnu.org>
	<wlvc7odt02.wl%mituharu@math.s.chiba-u.ac.jp>
Reply-To: Eli Zaretskii <eliz@gnu.org>
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 <mituharu@math.s.chiba-u.ac.jp>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 15 12:57:14 2013
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <eliz@gnu.org>) 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 <eliz@gnu.org>) 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 <eliz@gnu.org>)
	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: <wlvc7odt02.wl%mituharu@math.s.chiba-u.ac.jp>
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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/158921>

> Date: Mon, 15 Apr 2013 18:48:29 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 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.