From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: bug in 23.2.92 with anything Date: Mon, 17 Jan 2011 18:48:13 +0100 Message-ID: <4D3480DD.7020101@gmx.at> References: <87aaj2asy4.fsf@gmail.com> <4D31FDEC.9050508@gmx.at> <4D32D81B.5090905@gmx.at> <4D33301C.3080100@gmx.at> <4D337DE0.8010908@gmx.at> 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: dough.gmane.org 1295286513 18324 80.91.229.12 (17 Jan 2011 17:48:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 17 Jan 2011 17:48:33 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 17 18:48:29 2011 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.69) (envelope-from ) id 1PetBr-00073V-Uj for ged-emacs-devel@m.gmane.org; Mon, 17 Jan 2011 18:48:28 +0100 Original-Received: from localhost ([127.0.0.1]:33134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PetBr-0002zF-Br for ged-emacs-devel@m.gmane.org; Mon, 17 Jan 2011 12:48:27 -0500 Original-Received: from [140.186.70.92] (port=48731 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PetBh-0002wn-DZ for emacs-devel@gnu.org; Mon, 17 Jan 2011 12:48:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PetBg-00089N-46 for emacs-devel@gnu.org; Mon, 17 Jan 2011 12:48:17 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:50975) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PetBf-00088t-Og for emacs-devel@gnu.org; Mon, 17 Jan 2011 12:48:16 -0500 Original-Received: (qmail invoked by alias); 17 Jan 2011 17:48:14 -0000 Original-Received: from 62-47-37-221.adsl.highway.telekom.at (EHLO [62.47.37.221]) [62.47.37.221] by mail.gmx.net (mp039) with SMTP; 17 Jan 2011 18:48:14 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18smCEF1UwsuNC5zXWbMeDW+KRwDFXKvbYcQBm0dQ Xq8d9z7H97UvAs User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.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:134649 Archived-At: >>>> > /* When running redisplay, we play a bit fast-and-loose and allow e.g. >>>> > selected_frame and selected_window to be temporarily out-of-sync so >>>> > when we come back here via `goto retry', we need to resync because we >>>> > may need to run Elisp code (via prepare_menu_bars). */ >>>> > select_frame_for_redisplay (old_frame); >>>> > >>>> > It would be good to get rid of such risky code. >>>> >>>> Is there any reason why this should not select the window too? >>> By "this" you mean what? IOW, who or what should "select the window >>> too"? >> This code. That is, select_frame_for_redisplay. > > What would be the utility of doing so? The redisplay will next call > redisplay_windows, which walks the entire window tree and redisplays > each one of them (temporarily selecting its buffer in the process). > How would selecting the frame's selected window help anything in this > procedure? I won't expect selected_window to play any significant > role in the redisplay process, because it redraws all windows. I don't know enough about redisplay. IIUC select_frame_for_redisplay is used mainly to set up frame local variables for displaying all buffers shown in that frame. In display_mode_lines selected window and selected frame are both temporarily deselected but in update_tool_bar only the selected frame is deselected (just as in select_frame_for_redisplay). If code is run in between, the fact that the selected window is not on the selected frame might be surprising. But I don't know what any code run by update_tool_bar or redisplay_internal really needs in this context. So if you say it doesn't matter I take your word for it. martin