From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bastien Newsgroups: gmane.emacs.devel Subject: Re: save-frame-excursion? Date: Sat, 25 Jul 2009 19:42:00 +0800 Message-ID: <871vo5c7lj.fsf@bzg.ath.cx> References: <87ocrb8fy0.fsf@bzg.ath.cx> <4A691B47.1050102@sift.info> <4A692A6A.4080601@sift.info> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248522265 17772 80.91.229.12 (25 Jul 2009 11:44:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jul 2009 11:44:25 +0000 (UTC) Cc: emacs-devel@gnu.org, Carsten Dominik , Robert Goldman To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 25 13:44:18 2009 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 1MUfdt-0001Zv-VF for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2009 13:42:22 +0200 Original-Received: from localhost ([127.0.0.1]:56870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUfdt-0007rx-CD for ged-emacs-devel@m.gmane.org; Sat, 25 Jul 2009 07:42:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUfdm-0007ni-Og for emacs-devel@gnu.org; Sat, 25 Jul 2009 07:42:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUfdh-0007bh-Sy for emacs-devel@gnu.org; Sat, 25 Jul 2009 07:42:14 -0400 Original-Received: from [199.232.76.173] (port=41980 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUfdh-0007bA-8p for emacs-devel@gnu.org; Sat, 25 Jul 2009 07:42:09 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.241]:30816) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUfdg-0008Pk-AH for emacs-devel@gnu.org; Sat, 25 Jul 2009 07:42:08 -0400 Original-Received: by rv-out-0708.google.com with SMTP id f25so906360rvb.6 for ; Sat, 25 Jul 2009 04:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :in-reply-to:references:user-agent:date:message-id:mime-version :content-type; bh=BAv1e53wEofABYqWCV6HfTqFr2du+EzfKnyFGzmR/tE=; b=kEwbWqNF783o/KmbUwZBgj2HMtsCgGQpO2s3XEfuiExSQQQNJNKwpCbN3vZ645k5bQ 2i4+QsirIstIpv/bdxEhVvr54dg0ARTqqIeD6LmxByw3xthW4WbBM2aefis3QpJcDWdD Oe2U59w3VKweqf+CBOpxfXOsb32IuW2e5jrvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; b=AdE7LW5nk4oVXUpB+7vj7V+TmLyqqMJ+x4YyKrpiAuqY9/h1sjApv/A0TzY1rB2Rqf 6hwUVYl2Hz8lnsVix4Lal/RxK0bYqf8CJlgcP0JLub7knIjMq8y/4bw8ZJdiyzQcDKsR xGHHCZ/567sl86BOypgoEoDDXuE6KK62HsOi8= Original-Received: by 10.141.29.14 with SMTP id g14mr2964779rvj.261.1248522127498; Sat, 25 Jul 2009 04:42:07 -0700 (PDT) Original-Received: from bzg.ath.cx ([222.29.50.13]) by mx.google.com with ESMTPS id c20sm20434377rvf.51.2009.07.25.04.42.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 04:42:06 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 24 Jul 2009 15:24:33 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:113132 Archived-At: Stefan Monnier writes: >> The calendar buffer was configured to be sticky in a particular frame, >> so that when emacs wanted to show that calendar buffer, it showed it in >> the different frame. > > That still doesn't explain the shift of focus. Briefly, here is how org-read-date works: - if org-read-date-popup-calendar is t, it pops up a calendar, either in a different window, either in a different frame, depending on the user configuration; - it prompt the user for a date (and possibly more information like the time, the repeater, etc.); - it add new commands to the minibuffer-local-map: these commands modify the calendar display. For example, M-S- will call this command: (org-eval-in-calendar '(calendar-backward-month 1)) - those minibuffer commands get a post-command hook which displays the calendar according to the minibuffer prompt. That's the basic mechanism. For org-read-date to work when the calendar is displayed in another frame, we need to prevent org-eval-in-calendar from losing the frame focus. I've just pushed a change to Org that spares us org-save-frame-excursion by making `org-eval-in-calendar' DTRT about restauring the frame focus. >> I don't entirely understand how the stickiness happens -- configuration >> of the emacs calendar is far beyond me. > > Doesn't matter. If the code doesn't explicitly ask for a change in > focus, then there's no reason (other than to work around a bug > somewhere, probably) why we need to reset the focus via > select-frame-set-input-focus when unwinding. The code was indirectly asking for a change in focus by calling the calendar from within a command. >> Admittedly it's unlikely (at least now) to get into a state where you >> will change the frame focus, but whenever you /do/ change the frame >> focus, wouldn't you want it restored? > > Emacs almost never changes frame focus explicitly (for the good reason > that it's mighty hard to do it reliably for all possible WMs). I am not using frames so I was not aware of these issues until now, and I agree changing frame focus explicitely is not very good. Maybe we should have an option `org-calendar-force-display-in-window' defaulting to t to prevent the calendar to be displayed in a separate frame. -- Bastien