From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Getting rid of selected_window Date: Fri, 29 Nov 2013 11:54:13 -0500 Message-ID: References: <5298804A.5040405@yandex.ru> <83fvqf6xrp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385744468 18157 80.91.229.3 (29 Nov 2013 17:01:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 17:01:08 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 18:01:12 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmRRI-0003Xp-PC for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 18:01:12 +0100 Original-Received: from localhost ([::1]:48420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmRRI-0002ab-Aq for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2013 12:01:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmRKq-0000to-Kq for emacs-devel@gnu.org; Fri, 29 Nov 2013 11:54:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmRKj-0005a6-A0 for emacs-devel@gnu.org; Fri, 29 Nov 2013 11:54:32 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:18563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmRKY-0005WX-Qz; Fri, 29 Nov 2013 11:54:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KEh/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZZ7hR6BXoMV X-IPAS-Result: Av4EABK/CFHO+KEh/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZZ7hR6BXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="40698742" Original-Received: from 206-248-161-33.dsl.teksavvy.com (HELO pastel.home) ([206.248.161.33]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 29 Nov 2013 11:54:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 8683160EFA; Fri, 29 Nov 2013 11:54:13 -0500 (EST) In-Reply-To: <83fvqf6xrp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Nov 2013 17:19:38 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165884 Archived-At: > What for? I don't think you can get rid of the need to synchronize > those, because of features like focus redirection and minibuffer-only > frames. AFAIK these don't interact at all. IOW they're unrelated. > I don't understand what is the difference between Fselected_window and > SELECTED_WINDOW. Why do we use both in C? It's confusing. Indeed, it is confusing. Part of the confusion comes from the current code, tho. This is an opportunity to clarify the code. > SELECTED_WINDOW can return NULL, and then this dereference will > segfault. This is the crucial part of the difficulty: figure out which part of the code needs to pay attention to the case where there's no selected-window yet. I think SELECTED_WINDOW should never return NULL. Instead, we should have a new function to test if there is a selected-window, and call it explicitly before SELECTED_WINDOW, at those rare places where such is needed. > This changes the semantics of selected_window, because it requires > that its frame be live. Indeed the Fframe_live_p check shouldn't be in there. If there are places where such a check is needed, then let's add the check at those specific places. > So now we have SELECTED_BUFFER and current_buffer, which are > different in unspecified ways. Yes, we now have it, and this patch won't change that, other than giving a name to the concept of "selected buffer". > What do you think is the probability that someone will use the wrong > one of that pair? I think it's 100%. That's already a risk and such errors already happen. This said, I think that instead of selected_buffer, we should use the name selected_window_buffer, to make things more clear. Stefan