From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: master b3dd0ce: Provide new option `delete-window-set-selected' Date: Thu, 10 Jun 2021 17:01:59 +0200 Message-ID: References: <83a6nycdz7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5276"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 10 17:03:19 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lrMDF-00013K-K6 for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 17:03:17 +0200 Original-Received: from localhost ([::1]:39410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrMDE-0006Pj-Ic for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 11:03:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrMC7-0005H2-QG for emacs-devel@gnu.org; Thu, 10 Jun 2021 11:02:07 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:60159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrMC5-0003za-A9; Thu, 10 Jun 2021 11:02:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1623337321; bh=pxnInTsBkDBLUglrkOuuzyeDKMgWiRaVLcDBpcweL9s=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Ex2Sq2MjLouc4CH/stOZX/AyUkJkBG8vPuGzSoB1Cu+E3C8RI9LT+cE09FrPfw3rW DsbbPFr2Y0bNzcpIXuLBPSQ2+CW9VkkAU/HYm0uy1udH1KBJ8huBYartNeJIrZS3jX 2VFZuOFfPqB46qlPMeMKUwgMAeIPRZmKL9CycngM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.133]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MulmF-1l0Uck0TgZ-00rqJk; Thu, 10 Jun 2021 17:02:01 +0200 In-Reply-To: <83a6nycdz7.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:TXJKqI8XoiO9Uq3WdZgMlFCJ8NU2cRoDhnYAXCNq11IaLVOLMOV KaNl3s/rns6Iv+fpfxyKOQtg7C9UuahV4m8nv711Hcq3GU2fPmMBwKiZ9KK4am0OdWNNjfU e+0+sNRQs3HuzLhUenMbdbWVCwer1riZVtBRezK7Xqkgf0Qs4KshkGCSpZ0LhBsgkDRg5J9 OWsDGJEeHLy2WAK/7NBEw== X-UI-Out-Filterresults: notjunk:1;V03:K0:VWwwrx6Azm8=:CHiJnsHMmrU/uBgHdI8UVV haqnwb+DHEUql0UJG934IQKlS3j76y3GWT/BM49UX/L89L2Zds6E42CRuVN+XLv7XpOtskivS Gj3jcmpIUuZEPg5hr+xGDeVkaJH3aYH35yI6xpIf+GCaeQ9ZmJ0ugg23obpt8fr6ax2rnt3mV Nfrdjj1FOlg8GHOuG/Oewb9vzefp4UwOqK3P5LfCPM9JtZqIzU1BL8R2yxt6asGqUU9/mNRtG dJadCW8g/WEX4JLGvrOz/Ytns/r4INwUmOxoCzh2gL+40xXMGBmQ7BbOvXTYJsoG94kzD93Xq 55yRzCEwFAozu0Rn6c130zmkZHYJf+YjGcnyZLUdxYH1XE8oi+pF2sPcmZ6DgFaDcoSCwTUC5 8rkTZgnkNOlGVXgHvQYnkRI3vNxCDyFwhTyfeAy8Sv/2RUu1/Y66VTn8BjpwdxHqD3lVF24W4 vIy34CsbK0Vl8KiUi4FewhehsYNykAOnuyvKiBH9ffMSxE5zmmlDzCq1AOUf55oM1apw2CTvf vO4AVVTQ2J81UBsEFUjCDN6hqchpkl5KZOoXSCEdAA/5V6BMcr9/ABTigMMEKpQyOs3RxPW38 3R56ZqLqH0JJcXFhxWVf8beEA/4/R907BcroXCRmRwLI7YP6KyOhdCgSUA8l48o7ZdRABbTdJ QDRhmMsl5bdPQywa6iIBr60iCf8NUvdnEOCUCuuBgtpYBJQpBC/wiH9hB7MimhNdS8sZEOE5F Q7wANrzt1yyOYvI82Dh1pJ9+OifMus/Rww4is1sCWY6SbGB3AXqR79DNmHXFcel7p00KgI+V Received-SPF: pass client-ip=212.227.17.20; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270646 Archived-At: > A few comments about this changeset: Appreciated! > Why a variable that is a user option is documented only in the ELisp > manual? I think it should also be mentioned in the "Change Window" > node of the user manual, where we describe "C-x 0" and "C-x 1". In a restricted sense I suppose because we nowhere describe terms like "frame selected window" or "most recently used window" there. So in the C-x 0 paragraph something like "The option @code{delete-window..} allows to choose which window becomes the new selected window instead." should do what you have in mind here. OK? >> + Note that a window with a non-@code{nil} >> +@code{no-other-window} parameter is never chosen. > > Doesn't this depend on some argument to the relevant functions? Yes. I have added such an argument to `get-mru-window' and friends. But see my last remark below. >> @cindex largest window >> -@defun get-largest-window &optional all-frames dedicated not-selecte= d >> +@defun get-largest-window &optional all-frames dedicated not-selecte= d no-other >> This function returns the window with the largest area (height time= s >> -width). The optional argument @var{all-frames} specifies the window= s to >> -search, and has the same meaning as in @code{next-window}. >> - >> -A minibuffer window is never a candidate. A dedicated window >> -(@pxref{Dedicated Windows}) is never a candidate unless the optional= >> -argument @var{dedicated} is non-@code{nil}. The selected window is = not >> -a candidate if the optional argument @var{not-selected} is >> -non-@code{nil}. If the optional argument @var{not-selected} is >> -non-@code{nil} and the selected window is the only candidate, this >> -function returns @code{nil}. >> - >> -If there are two candidate windows of the same size, this function >> -prefers the one that comes first in the cyclic ordering of windows, >> -starting from the selected window. >> +width). If there are two candidate windows of the same size, it pre= fers >> +the one that comes first in the cyclic ordering of windows, starting= >> +from the selected window. The meaning of the arguments is the same = as >> +for @code{get-lru-window}. >> @end defun > > This hunk loses the information about minibuffer windows and dedicated= > windows, at least. it also seems to lose the information about when > the selected window isn't a candidate. Why? This information is now provided by the sentence "The meaning of the arguments is the same as for =E2=80=98get-lru-window=E2=80=99." just as = with the preceding `get-mru-window'. >> +(defun window-at-pos (x y &optional frame no-other) >> + "Return live window at coordinates X, Y on specified FRAME. > > A better name for this function is window-at-x-y, IMO. "Pos" can have= > ambiguous interpretations, see above. So `window-at-x-y' be it. >> +X and Y are counted in pixels from an origin at 0, 0 of FRAME's >> +native frame. A coordinate on an edge shared by two windows is >> +attributed to the window on the right (or below). Return nil if > > If you say "FRAME-relative coordinates", doesn't that tell the same > story, just much more succinctly and clearly? It does. >> +(defcustom delete-window-set-selected 'mru > > Wouldn't the name delete-window-choose-selected be better? I'll go for that unless Juri has a better idea. > The doc > string says that much: > >> + "How to choose a frame's selected window after window deletion. > > Or maybe delete-selected-window-choose-replacement? > >> + ;; If `delete-window-internal' selected a window with= a >> + ;; non-nil 'no-other-window' parameter as its frame's= >> + ;; selected window, try to choose another one. >> + (catch 'found >> + (walk-window-tree >> + (lambda (other) >> + (unless (window-parameter other 'no-other-window= ) >> + (set-frame-selected-window frame other) >> + (throw 'found t))) >> + frame)))) > > That "try" means that we could sometimes fail, and return a window > with a non-nil 'no-other-window' parameter, right? If so, the doc > strings, which say such a window will _never_ be returned, are > inaccurate, right? Functions like `get-mru-window' never return such a window provided their NO-OTHER argument has been set. The snippet you cite is from `delete-window' which, in that case, leaves the window selected by `delete-window-internal' alone and these doc strings are right. But I'll amend the documentation of the new option appropriately. Thanks, martin