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 16:59:31 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.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=US-ASCII X-Trace: ger.gmane.org 1366012790 8778 80.91.229.3 (15 Apr 2013 07:59:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Apr 2013 07:59:50 +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 09:59:54 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 1UReKO-0003HK-RW for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 09:59:53 +0200 Original-Received: from localhost ([::1]:55041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UReKO-00022b-HI for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 03:59:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UReKJ-0001z7-G5 for emacs-devel@gnu.org; Mon, 15 Apr 2013 03:59:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UReKH-0006MN-Qy for emacs-devel@gnu.org; Mon, 15 Apr 2013 03:59:47 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UReKA-0006I6-Vh; Mon, 15 Apr 2013 03:59:39 -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 C94D5C055D; Mon, 15 Apr 2013 16:59:31 +0900 (JST) In-Reply-To: <83d2tw73h7.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:158915 Archived-At: >>>>> 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+. 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. > 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. I think it is natural and the expected behavior actually. The current code uses wrong information (i.e., the value of `cursor-in-echo-area' as of "expose") in this respect. Again, the bug itself is not specific to a single platform. > Also, there are several details that need to be figured out: > . 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. > . should this flag of the current_matrix be cleared after the > cursor is displayed? If not, how can we be sure that during the > next redisplay cycle, optimizations that bypass most of glyph matrix > construction will not use a stale value? > . what if redisplay was preempted? in that case, > set_window_cursor_after_update is not called, and the flag keeps its > previous value even if cursor_in_echo_area has changed. > etc., etc. > IOW, I'm unhappy with this change, and would like much better a > solution that doesn't affect every platform out there (including > text-mode display, btw). 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. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp