From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Manual suggestions for quit-restore documentation Date: Fri, 24 Mar 2017 10:03:52 +0100 Message-ID: <58D4E0F8.10500@gmx.at> References: <87varoh5ka.fsf@ericabrahamsen.net> <58BBE3DB.7000000@gmx.at> <8737e37ozr.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1490346379 12090 195.159.176.226 (24 Mar 2017 09:06:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Mar 2017 09:06:19 +0000 (UTC) To: Eric Abrahamsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 24 10:06:16 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crLAj-0002RU-8i for ged-emacs-devel@m.gmane.org; Fri, 24 Mar 2017 10:06:13 +0100 Original-Received: from localhost ([::1]:60351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crLAp-0000ni-7m for ged-emacs-devel@m.gmane.org; Fri, 24 Mar 2017 05:06:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1crL8g-0008LG-KO for emacs-devel@gnu.org; Fri, 24 Mar 2017 05:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1crL8f-0005NM-GO for emacs-devel@gnu.org; Fri, 24 Mar 2017 05:04:06 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:62076) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1crL8f-0005MO-6K for emacs-devel@gnu.org; Fri, 24 Mar 2017 05:04:05 -0400 Original-Received: from [192.168.1.100] ([213.162.68.120]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MaZrd-1cc9lT3OCP-00KD3f; Fri, 24 Mar 2017 10:03:54 +0100 In-Reply-To: <8737e37ozr.fsf@ericabrahamsen.net> X-Provags-ID: V03:K0:2rIvR9mrixFcM6rF8gXCUK+Z1dzEpVTJ1MKgVZ8LEFYRXUBH31Z wDJAsgUHG4pPo3eQjRTBV22gyCHAUKJ603z8VgDo8b0ofvKS07hmixfUVofi14PccC1oksR Jx6VQl0BwNJaPcQChyJOJL4+o8laZh4yQOJlLWCqOTnLz6U3opqNVbYmV7c8v1ZwCsVCDS/ bpNVaeNSKoa3+mhIZzfZQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:qr1IGUDmLnY=:UbuvKQQqlREyuZ8Xt8UYCC jHiR0Yfu3vpMn6Fd5SDO1hDoeuRZJvpsbsTn2uX0J4yW/Wu2Sp4TxaohSBzg2ELe7Er7QGgY0 IZFDKIHzpnpx+gbsGRq38dBubfGelSoAd29zoLE6EhWJKa7NMsNiWkFazpgw90v57CGEdRbq9 /Mu8KvjqFeKck3uDlebMtyjQUDU358hHbr5cGrKaipgSizCZQvy3pyo2Ua4F0fXj5yu/A6bvd cpraQxZCzGyc3dzZEkmAIzzq18tw/7pRBe7c6oIQPiWauUSiHZUEo2/tJGFDpiiGginI27892 N7VlA4sa9D2diHechh2u4+fcsqUSGdogWomMS03V2YgjyGgnPiTL7bpgAW/lQ7flmoN2qVnHW MUPqZ1GaH51UTqiamfsfYi8/ao/VTEtUjkE8rKlhknqyQb32W0CsJ4cMDdb/KxNez+uMjJcNL Wyg8NNmqlA9TXc+ltDrZ03zGR9PonErifoKRVbF9qYkoJUU5panUL5Se0Fe/5eyB77wq9zTlP KCdi7jLbl3Bom5LC9NVjKAQYD8jiRPwUXrZm/cn4AIkNJjr71EcuTWasnYcUr6KXCu1t1CYEd 8xGeIcdqhHGtMB+2mM4A9/GOsWVBAyYQlEmtjNWpUasTHiJMI1K/QeeJVB4AfmbBagIdn0JQ6 3m95o91ScmM8hc6FR1cZWI8HGGBg/+4M/Z/fQOLypiKxLK2Tm66ny3Wc7MJSUiGfEzBykm9Ko YM2jKQkfF6X6IUK/FaUXsBNfD4ycIN1Ti/FmSvx94wwOSyAgpa1QD5t+44pan9MkbaC2sFlS X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:213285 Archived-At: > I just don't see how/where the `bury-or-kill' parameter affects the > handling of the frame, I think it only affects the buffer. But I may > have "fixed" it until it doesn't make sense :) Isn't that via (defun quit-restore-window (&optional window bury-or-kill) ... ;; Delete WINDOW if possible. (window--delete window nil (eq bury-or-kill 'kill))) and (defun window--delete (&optional window dedicated-only kill) ... (cond (kill (delete-frame frame)) or what am I missing? > I added a line about 'same as the first element of `quit-restore', but > it might be wrong. > > I didn't add anything new about the 'other symbol. I see it getting set > in `display-buffer-record-window', but I don't see that it ever gets > used. I suppose it's used here (defun quit-restore-window (&optional window bury-or-kill) ... ((and (listp (setq quad (nth 1 quit-restore))) (buffer-live-p (car quad)) and it's essential when the window was used for showing an "other" buffer. > +however, if it is the only one in its frame. If @var{window} is the > +only window on its frame and there are other frames on the frame's > +terminal, the value of the optional argument @var{bury-or-kill} > +determines how to proceed with the window. If @var{bury-or-kill} > +equals @code{kill}, the frame is deleted unconditionally. Correct IMHO. So what is still unclear about `bury-or-kill'? > +possible to set it manually, using the following code when displaying > +``buffer'' in ``window'': Both `buffer' and `window' are arguments so I'd use var{} here. > +The final use of @code{set-window-prev-buffers} ensures that a future > +call to @code{quit-window} will delete the window altogether. > + I'd prefer something like "Setting @code{set-window-prev-buffers} _to nil_ ensures that a future call to @code{quit-window} _can_ delete the window altogether." > +window showed another buffer before. The 'frame and 'window elements I think we use `frame' and `window' instead of 'frame and 'window. > +re-uses the window to display the buffer. Would "reuses" be bad English? Thanks for working on this, martin