From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Frame size changes Date: Fri, 03 Oct 2008 14:15:52 -0400 Message-ID: <873ajdtuhz.fsf@cyd.mit.edu> References: <877i8qvq5k.fsf@cyd.mit.edu> <48E5C4E5.9040400@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1223057720 8234 80.91.229.12 (3 Oct 2008 18:15:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Oct 2008 18:15:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jan =?utf-8?Q?Dj=C3=A4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 03 20:16:17 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KlpC7-0005NV-BI for ged-emacs-devel@m.gmane.org; Fri, 03 Oct 2008 20:16:03 +0200 Original-Received: from localhost ([127.0.0.1]:39036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlpB4-0007br-2w for ged-emacs-devel@m.gmane.org; Fri, 03 Oct 2008 14:14:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KlpAl-0007Uf-KQ for emacs-devel@gnu.org; Fri, 03 Oct 2008 14:14:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KlpAk-0007UF-Fh for emacs-devel@gnu.org; Fri, 03 Oct 2008 14:14:38 -0400 Original-Received: from [199.232.76.173] (port=44724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlpAk-0007U2-0z for emacs-devel@gnu.org; Fri, 03 Oct 2008 14:14:38 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]:36660) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KlpAj-0004hn-Mo for emacs-devel@gnu.org; Fri, 03 Oct 2008 14:14:37 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id C4E8C57E08D; Fri, 3 Oct 2008 14:15:52 -0400 (EDT) In-Reply-To: <48E5C4E5.9040400@swipnet.se> ("Jan =?utf-8?Q?Dj=C3=A4rv=22's?= message of "Fri, 03 Oct 2008 09:08:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104331 Archived-At: Jan Dj=C3=A4rv writes: > Emacs calculates the frame size based on some initial font, and sets > wm manager hints based on that (i.e. restricts width/height to a > multiple of the font width/height). > > Then Emacs reads .emacs and that changes the font, thus a new size and > a new wm hints is calculated and a new frame size is set. > > The window manager applies the size hints and sends configure notify > to Emacs when it does. But if Emacs has read the second font size > before the ConfigureNotify for the first font size changes arrives, > things get strange. The window manager bases the size on the first > font, but Emacs bases it on the second. So when Emacs tries to cope, > it probably does a resize again (because the fonts sizes differ and we > want the frame to be a multiple of the font size). This may lead to > another ConfigureNotify, which may be based on the first or second > font size (resize from Emacs and setting of wm hints does not go the > same way and can be seen out of order by the WM), there is a race > there. And the same thing happens again. Thanks for the explanation. I think this is indeed the problem. The straightforward fix is for Emacs to wait until the window manager gets back with the ConfigureNotify before proceeding. From looking at gtkutil.c, it seems like you use the function flush_and_sync for a similar reason. The problem, I'm guessing, is that we aren't guaranteed that the window manager will have a response ready during the flush_and_sync. If so, how about changing flush_and_sync to be more aggressive, and demanding a ConfigureNotify before proceeding? > I've tried many solutions but they all fail in some case or another.. > I think the only proper solution to this is to make Emacs read .emacs > before it maps the first frame. This would be a big incompatible change, and at this point in the release cycle we must exhaust all other workarounds before considering it.