From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Understanding atomic window groups Date: Sat, 15 Jun 2019 10:16:57 +0200 Message-ID: <051e3c42-a7ec-bd86-413a-914de818d375@gmx.at> References: <87tvdmqsxq.fsf@ericabrahamsen.net> <0a820a2c-8b37-469e-6b0e-61b126b6c7b8@gmx.at> <87lfyxszb5.fsf@ericabrahamsen.net> <875zpzedy5.fsf@ericabrahamsen.net> <171bed6b-96d6-0fa0-f4f4-b09cb72c7192@gmx.at> <87lfyucxfx.fsf@ericabrahamsen.net> <26d5d317-df88-fed9-1eb5-e5f0cb07bd25@gmx.at> <878suibcu8.fsf@ericabrahamsen.net> <52ea0859-0e57-b2a9-5798-8328596b9630@gmx.at> <87muinzv9b.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="256595"; mail-complaints-to="usenet@blaine.gmane.org" To: Eric Abrahamsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 15 10:18:39 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hc3tX-0014d0-Cy for ged-emacs-devel@m.gmane.org; Sat, 15 Jun 2019 10:18:39 +0200 Original-Received: from localhost ([::1]:59282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hc3tV-0007m1-WB for ged-emacs-devel@m.gmane.org; Sat, 15 Jun 2019 04:18:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50451) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hc3sX-0007jQ-1x for emacs-devel@gnu.org; Sat, 15 Jun 2019 04:17:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hc3sN-0002kk-7q for emacs-devel@gnu.org; Sat, 15 Jun 2019 04:17:35 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:36165) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hc3sF-0002Yi-5f for emacs-devel@gnu.org; Sat, 15 Jun 2019 04:17:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1560586617; bh=+yFvc9AVzHIo5CBtqjmXAYXJtp51MKGy8m6XUthkyY4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=NJm/biQPpViKAelnzBNdxSNYkKD7xNmQgqf49WA//mdT61iggN0J1i7u/cxJPBB5E WUacS/EMqiOwTY2H1MPk8s3M1Wx0mBOM4WKCIJsAving2mhc/agTWpxyitTJ8JMowj gkjUYuj9WsKD4N6TfJAQ3+6ewupsprRRWrXX9eD4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([213.162.73.177]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MMBun-1hhqce2m5t-00869W; Sat, 15 Jun 2019 10:16:57 +0200 In-Reply-To: <87muinzv9b.fsf@ericabrahamsen.net> Content-Language: de-DE X-Provags-ID: V03:K1:rNQQi4WUR0ElswXxrMoTaTZ4U/sNTS2zyIFqVLhiBA8e+MMOzHX 9QbDS8HVZDxBqmgItIQ/tr2xO1MbcIC/laozr6x6up0WgUIUqjlKxn2nD82ACglsa/ZTlM6 fW9aMD2msivzpxidxpYOG3z5yzNr5UjeHqRO+4Ru82QQX8DVAAyAgRh3GVAcV2P3z5wvbWe I6e0qBWQA5wENrXat/r4g== X-UI-Out-Filterresults: notjunk:1;V03:K0:iBl8c2roQRA=:liL2B1MyNiKOUVNO8yI1qr AJhTxNLMfq08iykdJhfvyFpdaeDi1kwQi6cAnDwLV30k7wuOsE565K/VooEoXWB3oaXGRnfCh fJMzQH3yNFTHotUooA0arJWGqI3IESH2SNeI6ubUtRMOchbHo57xfKbhhuoVSQoc7crur+lBZ /yrj49UERlkYm6a0PV55SO2WzH4DtmzqGZYS6/4TUT6ifE0jplN+srQLhNwNVLr3z+eg3fdpD hSaXQJ3HAKqQF2MuO1awS6Q+fBgF5BVD91v9l7zcPw0fCSAMgH50G76DfelUQ0iM2GWR8+VT0 +9UihwFtNlq0aIRYI5uIfcj5TN88zn37gPbnEPVshObyYc8bKuo+4xFQjl/tXeGaJJ7b5agWs F0yLdSttrAeBg8Dq1XB3QMCC9L8+Ke03xgnAcfh634iqOed9C5gtxdK64vrpXFdcxL6P90N4Z t39N0qUMw5PPNURDQtUqsfKO4F1AaoZYmvDyR8rA1D/om67z6OwnJ1Fz1cfpsMSIJVWwTXmsu S1MbF8IKoqCMyFvOIjwO8ncYVbis46IMb70j7PuMgeXxzR9VPOaPFSvUeTzYrVBfhtf2roSOc dbrAD2iNUAjeHZVqefE6JQFIYgpb2EJHwwfKA6J/d3ZzGVtJkaoam0NougLq255zib90jNzXq dVEhhnsEl6BahVkaUUZtwkRqGuwSm4xFIQxkoH7KA9zYjdYuekIOGkToMyK82k9cyb4TcdIzK bDHY1abDhNEMjhGSlOtnnln1A+5b9wtH233kcXdHzPd1wYgHoXhllTXBIpruYr95k62fEo+G X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237657 Archived-At: > I've had a whack at updating the manual, and attached a diff. This is > obviously just a first try, and I imagine there will be much that needs > to be tweaked. To be honest, several of the examples in the manual > didn't work as advertised when I tried them, but I guess that's a > separate problem -- this is how it's _supposed_ to work, I think. Thanks. > - As you mentioned, `gnus-use-full-window' should be obsoleted in favor > of `gnus-use-full-frame'. You should also specify _when_ things (liek the value of this variable) take effect. Note that with "window states" (Elisp manual section 28.26) users should be able to save specific gnus layouts and put them back into arbitrary windows, so maybe this variable is not so important in the first place. > - It would be nice if the size spec also accepted the symbol `fit', > which would trigger a `fit-window-to-buffer'. 'fit-window-to-buffer' might be hairy sometimes - triggered too often it can be noisy and fitting adjacent windows can inherently cause conflicts. Maybe you also want some sort of fallback size when fitting fails. Some loose remarks on your changes and what they change: 'gnus-buffer-configuration' really means 'gnus-window-configuration' although it's not a window configuration in the Emacs sense - maybe 'gnus-windows-layout' would be better. The @dfn{key} is a symbol that names some action or other. For instance, when displaying the group buffer, the window configuration function will use @code{group} as the key. A full list of possible names is listed below. Why this restriction to "possible names"? What if a user wants to switch between two layouts both comprising the group buffer? Below you then say "the @code{message} key is used for both @code{gnus-group-mail} and @code{gnus-summary-mail-other-window}. If it is desirable to distinguish between the two, something like this might be used" which IIUC means that the same symbol might name two different layouts? Is that a good idea? "The @dfn{value} (i.e., the @dfn{split}) says says which buffers to" has one "says" to many. Also, since it's much more than a split I would use a term like "layout" instead. Below you also talk about sub-splits/subsplits which somehow increase the confusion. Point will be put in the buffer that has the optional third element @code{point}. "Point" is inappropriate here. IIUC this just specifies the window to select. At each level of split depth, there @emph{must} be one and only one element that has the 100% tag. Is that restriction really needed? If all buffers mentioned in the configuration are already visible, Gnus won't change the window configuration. If you always want to force the ``right'' window configuration, you can set Why is this useful and in which occasions does it apply? Finally, it seems that there is no way to "save back" into 'gnus-buffer-configuration' a layout that has been obtained by "manually" changing an existing layout. Right? Wouldn't that be desirable? martin