From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Tue, 01 Jun 2010 11:24:15 +0200 Message-ID: <4C04D1BF.9070902@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <871vdu6qn5.fsf@mail.jurta.org> <87bpcv1wvt.fsf@mail.jurta.org> <4BE13828.2030609@gmx.at> <87vdb2qo82.fsf@mail.jurta.org> <4BE27C17.3030005@gmx.at> <87vdav4vx5.fsf@mail.jurta.org> <4BE900E7.3090402@gmx.at> <87r5liqv8f.fsf@mail.jurta.org> <4BEA74DC.2060103@gmx.at> <87y6fns8qo.fsf@mail.jurta.org> <4BECF4D6.9030707@gmx.at> <87632na2af.fsf@mail.jurta.org> <4C03F1B5.8040708@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1275384719 15729 80.91.229.12 (1 Jun 2010 09:31:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Jun 2010 09:31:59 +0000 (UTC) Cc: Juri Linkov , Emacs To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 01 11:31:54 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OJNp9-0001t0-N8 for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 11:31:52 +0200 Original-Received: from localhost ([127.0.0.1]:57124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJNp8-00073g-GP for ged-emacs-devel@m.gmane.org; Tue, 01 Jun 2010 05:31:50 -0400 Original-Received: from [140.186.70.92] (port=36800 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJNlp-0005mG-PY for emacs-devel@gnu.org; Tue, 01 Jun 2010 05:28:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJNhr-0004RZ-UA for emacs-devel@gnu.org; Tue, 01 Jun 2010 05:24:21 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:45194) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OJNhr-0004RH-Hu for emacs-devel@gnu.org; Tue, 01 Jun 2010 05:24:19 -0400 Original-Received: (qmail invoked by alias); 01 Jun 2010 09:24:17 -0000 Original-Received: from 62-47-40-60.adsl.highway.telekom.at (EHLO [62.47.40.60]) [62.47.40.60] by mail.gmx.net (mp024) with SMTP; 01 Jun 2010 11:24:17 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+zm8gjVDGz2+bFCOcOp4QG+9R5ENG9Cw1SLUstOT xpf0t1cqDPwjbi User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125422 Archived-At: >> (1) All calls to `other-buffer' for determining which buffer to show in >> a window have the second argument nil. So if a buffer is already shown >> in another window it's against some unwritten rule to show it in the >> window in question again. If I follow that rule, then working with two >> windows showing the same buffer remains just as tedious as it is now. > > Yes, the window handling code currently considers that the most likely > thing the user wants is to see a buffer that's not currently shown. > [ I'm not sure if it's careful to distinguish "shown on the current > terminal" from "shown in some other terminal, miles away from here", > which it should. ] It's not that careful. > This seems like a good default rule, so if we/you want to not follow > this rule in some cases, The case at hand was a scenario earlier posted by Juri as ... ------------------------------------------------------------------------ 2. Another example - visit the same buffer in two windows, and put point at different positions of the same buffer. +---------+---------+ | | | | dired 1 | dired 1 | | | | | | | +---------+---------+ Now view a file in the first window, and quit: `v q'. The window configuration is correctly restored (without using `set-window-configuration') - good. Now do the same without `view-mode': `RET C-x k'. Instead of the original buffer, some random buffer is displayed in this window. ------------------------------------------------------------------------ ... which, together with another scenario, triggered the present discussion. > we should think about how we can tell which is > the better choice in a given situation. We could make this customizable. >> (2) The length of frame-local buffer-lists is unbound. For a one-frame >> user this already doubles the consing and maintenance overhead of buffer >> lists without any gain. If we add window-local buffer-lists, we'd >> double the current overhead once more for one window/one frame users. > > Is this overhead really significant? Say the list is 100 buffers long, > that's 1 or 2 KB, right? Isn't this lost in the noise? Look at the following stretch from `other-buffer': tail = Vbuffer_alist; pred = frame_buffer_predicate (frame); /* Consider buffers that have been seen in the selected frame before other buffers. */ tem = frame_buffer_list (frame); add_ons = Qnil; while (CONSP (tem)) { if (BUFFERP (XCAR (tem))) add_ons = Fcons (Fcons (Qnil, XCAR (tem)), add_ons); tem = XCDR (tem); } tail = nconc2 (Fnreverse (add_ons), tail); This prepends a list of (nil . buffer) conses for every non-buried buffer on the selected frame (or some specified frame) to the list of all buffers. Note that reusing a window in `display-buffer' doesn't bury the previous buffer. Now for one-frame Emacs users this means that its consing overhead is usually always proportional to the number of live buffers. Given the fact that `bury-buffer' (and thus `next-buffer') and evaluating the `b' and `B' interactive arguments all call `other-buffer' this makes me think that some GC overhead result. It shouldn't be too hard to fix this. [`other-buffer' has not been coded very cleanly, just try evaluating (other-buffer nil nil 1) in a _separate_ instance of Emacs.] Similar problems exist for `buffer-list' and `last-buffer'. >> (3) For each buffer on the window-local buffer-list I'd have to maintain >> its old point and its old window start position as markers. Otherwise >> restoring the buffer would either get me a silly position if the buffer >> was modified in the meantime (a rare case probably, but unacceptable >> nevertheless) or a useless position like `point' (which would usually >> coincide with `window-point' of some other window showing that buffer). >> This means that for each buffer we get as many additional markers as >> there are live windows in which the buffer was shown (times two). > > The use of `point' for that has not brought many complaints over the > many years it's been used. Any reason to think it's a bad choice? It's a bad choice if you show a buffer in two windows W1 and W2, temporaily show another buffer in W2, select W1, and switch back to the original buffer in W2. The whole "point" of showing the same buffer in two windows is lost. Note that if the temporarily displayed buffer is in view or help mode you don't have this problem since `view-mode-exit' handles the case. martin