From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Understanding atomic window groups Date: Sat, 15 Jun 2019 08:47:45 -0700 Message-ID: <877e9metpa.fsf@ericabrahamsen.net> 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> <051e3c42-a7ec-bd86-413a-914de818d375@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17761"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 15 18:15:06 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 1hcBKc-0004TI-I2 for ged-emacs-devel@m.gmane.org; Sat, 15 Jun 2019 18:15:06 +0200 Original-Received: from localhost ([::1]:33216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcBKb-00068H-BL for ged-emacs-devel@m.gmane.org; Sat, 15 Jun 2019 12:15:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36956) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcAuM-0006Ep-RL for emacs-devel@gnu.org; Sat, 15 Jun 2019 11:48:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcAuL-0000LK-70 for emacs-devel@gnu.org; Sat, 15 Jun 2019 11:47:58 -0400 Original-Received: from [195.159.176.226] (port=44072 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hcAuJ-0000Co-8i for emacs-devel@gnu.org; Sat, 15 Jun 2019 11:47:57 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hcAuF-000fQI-7D for emacs-devel@gnu.org; Sat, 15 Jun 2019 17:47:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:/foZ7gOI4DWQ5jr36OPF0KR2mkA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:237695 Archived-At: martin rudalics writes: >> 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. I can mention that this only takes effect when `gnus-configure-windows' is called. I'm not sure saving window state will be so useful: you might say a particular layout describes the relationship of the group, summary and article buffers, but the actual summary and article buffers will change continuously. >> - 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. Okay. That can wait until later. > 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. Yup, that would probably be a better name. > 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? In theory any key could be added to the alist, specifying any random window layout, but nothing would ever call that code. A user could write a function that calls `gnus-configure-windows' with their own symbol, but if they know to do that, I doubt these docs would stop them. > 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? I don't know, tbh. The two possibilities describe the same state, arrived at by different means. By that token you might want to distinguish between "group layout after starting Gnus" from "group layout after exiting a summary buffer". Maybe that would be desirable, but I haven't thought much about it. > "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. Oops, thanks for the catch. Yes, this should be more careful to distinguish between a split (which might contain further splits) and a layout (a top-level collection of splits). > 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. Yup, we could change this to 'select (and look for both, for backward compatibility). > 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? I think it is, at least implicitly... The existing docs mention that splitting by absolute line/column values might be imprecise (might be overridden by min/max window size specifications, or thrown off by rounding). So there needs to be a window where we can say "any imprecision will be rectified by adjusting this window". It would be awkward to use multiple windows to do that. We could have an implicit rule saying that the last window in a split might be subject to adjustment. In side-window terms, I suppose the 100% window could be considered the "main" window, in that its size isn't explicit: it's just whatever is left over after the other windows have been placed appropriately. But "main" might also imply selection (?), in which case the analogy doesn't work. > 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? Good question. I suppose if the user has manually adjusted a layout, they might not want Gnus to disturb that if it is functionally the same as the defined layout. But I really don't know. It doesn't seem very useful to me, either. > 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? Could be... We'd have to translate buffers back to windows using `gnus-window-to-buffer', then reconstruct the current window config into the "split" format, and put that layout into `gnus-buffer-configuration'. But that would only work for the current session. I guess I don't quite see the utility, unless I'm misunderstanding what you mean? Thanks for the review! Eric