From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Sun, 18 Sep 2016 17:39:06 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <57DE4306.6060904@gmx.at> <57DE4D33.6070201@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1474188000 23537 195.159.176.226 (18 Sep 2016 08:40:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 08:40:00 +0000 (UTC) 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) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 18 10:39:56 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blXde-00051n-G0 for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 10:39:50 +0200 Original-Received: from localhost ([::1]:49212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blXdc-0006D2-Ln for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 04:39:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blXd4-0006Cm-8O for emacs-devel@gnu.org; Sun, 18 Sep 2016 04:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blXd0-0004yS-4P for emacs-devel@gnu.org; Sun, 18 Sep 2016 04:39:13 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blXcz-0004xA-Mg for emacs-devel@gnu.org; Sun, 18 Sep 2016 04:39:10 -0400 Original-Received: from fermat1.math.s.chiba-u.ac.jp (fermat [192.168.32.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E4D59F08E9; Sun, 18 Sep 2016 17:39:06 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: <57DE4D33.6070201@gmx.at> 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.21 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" Xref: news.gmane.org gmane.emacs.devel:207529 Archived-At: >>>>> On Sun, 18 Sep 2016 10:15:47 +0200, martin rudalics said: >> When `frame-resize-pixelwise' is nil, the previous versions of the Mac >> port always respected the window size hints and did rounding. But >> this appears to interfere with "automatic window tabbing" introduced >> in macOS 10.12, so I restricted the cases where the size hints is >> respected. > I must be still missing something: Originally you said that > "we now round the frame size according to the character size only on > resize by mouse dragging or changes of the `fullscreen' frame > parameter" > which doesn't make sense to me: Rounding on resize by mouse dragging > doesn't seem reasonable to me because the frame edge will not follow the > mouse pointer but rather jump instead. Rounding when maximizing or > making a fullscreen frame, however, is much worse because it may leave a > maximized or fullscreen frame with empty space at anedge of the screen. > So I'm curious whether your description above just inverts the meaning > of what you actually do. Not actually. I think some of X11 window managers do rounding on resize by mouse dragging if `frame-resize-pixelwise' is nil (at least, quartz-wm does so). If user wants resize by mouse dragging to follow the mouse strictly, then she or he can set `frame-resize-pixelwise' to t. Also, unlike the NS port, the Mac port does not "white out" the screen during mouse dragging but updates the contents, and it is a bit heavy operation. Rounding during mouse dragging also acts as "coalescing" screen updates. (Actually, the way to implement this screen updating during mouse dragging on the Mac port interferes with "window snapping" introduced in macOS 10.12, so it is disabled if running on that version.) Rounding does not happen for the axis that is specified to be maximized/full so that it does not leave spaces. So, rounding happens only for horizontal axis when the fullscreen frame parameter is set to 'fullheight if `frame-resize-pixelwise' is nil. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp