From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Date: Thu, 04 Dec 2008 19:00:25 +0100 Message-ID: <49381AB9.3030602@gmx.at> References: "4922BD1F.2080604@gmx.at" <492DBE0C.1030707@gmx.de> <492EA390.1020206@gmx.at> <492EDCC9.7070806@gmx.de> <492EF976.1070108@gmx.at> <49319B2E.20006@gmx.de> <49325AAA.5090606@gmx.at> <1228089264.493327b06fd4e@webmail.freedom2surf.net> <49339200.7080603@gmx.at> <1228119737.49339eb964cc6@webmail.freedom2surf.net> <4933AFA5.5020109@gmx.at> <4934D1AF.50905@gmx.de> <49355A23.8030001@gmx.at> <49365CA9.8080302@gmx.at> Reply-To: martin rudalics , 1348@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1228414238 2099 80.91.229.12 (4 Dec 2008 18:10:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2008 18:10:38 +0000 (UTC) Cc: 1348@emacsbugs.donarmstrong.com, grishka@gmx.de, jasonr@f2s.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 04 19:11:40 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L8Ifr-0000h9-PC for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Dec 2008 19:11:40 +0100 Original-Received: from localhost ([127.0.0.1]:35438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8Ieh-0004zi-4Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Dec 2008 13:10:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8Ieb-0004vU-2u for bug-gnu-emacs@gnu.org; Thu, 04 Dec 2008 13:10:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8IeZ-0004sf-Qh for bug-gnu-emacs@gnu.org; Thu, 04 Dec 2008 13:10:20 -0500 Original-Received: from [199.232.76.173] (port=42344 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8IeZ-0004ry-7v for bug-gnu-emacs@gnu.org; Thu, 04 Dec 2008 13:10:19 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44564) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L8IeY-0000ZW-JS for bug-gnu-emacs@gnu.org; Thu, 04 Dec 2008 13:10:19 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mB4IADVd014682; Thu, 4 Dec 2008 10:10:14 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id mB4IA5R0014224; Thu, 4 Dec 2008 10:10:05 -0800 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 04 Dec 2008 18:10:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1348 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1348-submit@emacsbugs.donarmstrong.com id=B1348.122841380012091 (code B ref 1348); Thu, 04 Dec 2008 18:10:05 +0000 Original-Received: (at 1348) by emacsbugs.donarmstrong.com; 4 Dec 2008 18:03:20 +0000 Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id mB4I3Gab012074 for <1348@emacsbugs.donarmstrong.com>; Thu, 4 Dec 2008 10:03:18 -0800 Original-Received: (qmail invoked by alias); 04 Dec 2008 18:03:11 -0000 Original-Received: from 88-117-47-114.adsl.highway.telekom.at (EHLO [88.117.47.114]) [88.117.47.114] by mail.gmx.net (mp030) with SMTP; 04 Dec 2008 19:03:11 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18s0UF7CkYsfUbsZijSYtEu5zLW3wARaShHuVh+lG N1R/CSZsa7L0ET User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Thu, 04 Dec 2008 13:10:20 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:22945 Archived-At: > I don't see a need for giving an example for something that is so > blatantly wrong: it calls one thread's code from within another. > Since the Emacs input thread was written _specifically_ to overcome > problems with delivering input asynchronously, it should be clear to > anyone that mixing such threads is dead wrong, period. I can only _speculate_ on how Emacs is supposed to handle a frame size change requested by a Lisp routine. (1) Calculate (and internally store) the new size and send the WM (window manager) an appropriate request. (2) Continue the calling routine with the size calculated in (1). (3) When the WM confirmation finally arrives treat it as a resize request initiated by the WM. The idea seems that the sizes calculated in (1) and the size request in (3) coincide and no further resizing is necessary thereafter. Apparently Jason changed (1) on Windows in the sense that it does not internally store the new size. So if a Lisp routine issues another resize request before (3) is handled, (1) starts calculations with the values as they were before the Lisp routine started. The request that eventually gets processed by the Windows WM is the last resize/positioning request issued by the Lisp routine, with the values valid before the Lisp routine started. Now grischka's proposal seems to wait for the WM's confirmation within (1), that is embed (3) in (1), and have (2) proceed with the values promised (or confirmed) by the WM. This apparently runs counter to the ideology that the processing of asynchronous input should not happen in certain occasions and apparently a step like (1) is one of these. So the first thing we'd have to agree upon is whether we want a function like `set-frame-height' process messages of the WM. If we don't want that, we have to find another way to make `set-frame-height' DTRT which seems non-trivial to me. If we want that, we have to decide how to synchronize the handling of a confirmation message with the rest of system messages arriving around that time. For this purpose, we have to determine what can be safely processed and what must be processed to ensure liveness while waiting for the confirmation. (I suppose that's what Jason's "inter-thread synchronization" amounts to, though I don't understand the term "thread" in the present context - sorry. But maybe that's what ATTACH_THREADS was about.) Till we agree on something here I can test grischka's patches to know whether his approach can handle the problem at all - that is whether the confirmation gets through and is handled. martin