From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#4147: 23.1.50: Info-search command strange behaviour Date: Wed, 16 Dec 2009 16:04:02 +0100 Message-ID: <4B28F6E2.8020000@gmx.at> References: <20090815034957.GA30902@shareable.org> <4A86898F.6060508@gmx.at> <877ht2ryys.fsf@mail.jurta.org> <87k4x1b7vd.fsf@mail.jurta.org> <87bpi9uszm.fsf@mail.jurta.org> <87fx7d6x4j.fsf@mail.jurta.org> <4B26C372.9090008@gmx.at> <87r5qx155l.fsf@mail.jurta.org> <4B2745E5.2050108@gmx.at> <87my1johye.fsf@mail.jurta.org> <4B2891EC.4070500@gmx.at> <87hbrrgvq1.fsf@mail.jurta.org> Reply-To: martin rudalics , 4147@emacsbugs.donarmstrong.com 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: ger.gmane.org 1260979456 29439 80.91.229.12 (16 Dec 2009 16:04:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Dec 2009 16:04:16 +0000 (UTC) Cc: 4147@emacsbugs.donarmstrong.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 16 17:04:09 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NKwLt-0006wj-Pz for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Dec 2009 17:03:50 +0100 Original-Received: from localhost ([127.0.0.1]:49165 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKwLt-0007on-So for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Dec 2009 11:03:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKvmr-00063K-9Q for bug-gnu-emacs@gnu.org; Wed, 16 Dec 2009 10:27:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKvmm-0005xw-P7 for bug-gnu-emacs@gnu.org; Wed, 16 Dec 2009 10:27:36 -0500 Original-Received: from [199.232.76.173] (port=38294 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKvmm-0005xf-J9 for bug-gnu-emacs@gnu.org; Wed, 16 Dec 2009 10:27:32 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:45326) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NKvmm-0007D9-9o for bug-gnu-emacs@gnu.org; Wed, 16 Dec 2009 10:27:32 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nBGFRTau014604; Wed, 16 Dec 2009 07:27:30 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id nBGFA7kL012354; Wed, 16 Dec 2009 07:10:07 -0800 Resent-Date: Wed, 16 Dec 2009 07:10:07 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 16 Dec 2009 15:10:07 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4147 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: patch Original-Received: via spool by 4147-submit@emacsbugs.donarmstrong.com id=B4147.126097585310918 (code B ref 4147); Wed, 16 Dec 2009 15:10:07 +0000 Original-Received: (at 4147) by emacsbugs.donarmstrong.com; 16 Dec 2009 15:04:13 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nBGF4A8W010915 for <4147@emacsbugs.donarmstrong.com>; Wed, 16 Dec 2009 07:04:12 -0800 Original-Received: (qmail invoked by alias); 16 Dec 2009 15:04:04 -0000 Original-Received: from 62-47-34-13.adsl.highway.telekom.at (EHLO [62.47.34.13]) [62.47.34.13] by mail.gmx.net (mp014) with SMTP; 16 Dec 2009 16:04:04 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+e2SFAEyeebVT5m7Pj9lE672yPQAYzO44ky4a/D/ elEIOUAq/ucoVc User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87hbrrgvq1.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 16 Dec 2009 10:27:36 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:33638 Archived-At: > I think no need to relay back because a keymap click in a "header-line" > window will call a function that updates `header-line-format' whose new > content will be displayed in this window anyway. But you want to display the buffer the tab stands for in the other window and not in the window where the tab appears. That has to be handled. > This means we need extra buffer per every header-line. Yes. > I don't understand how do you intend to ensure that the tabbar > of the selected window doesn't disappear if the user types > `C-x 1' (`delete-other-windows')? Windows code can investigate all sorts of window parameters - in the present case there would be parameters like "nodelete", "noresize", "nosplit" and "noother" say. Now consider a configuration like this -------------------- | T | |--------------------| | W | | | | | | | | | -------------------- where T is the tabbar window and W the window (live or internal) the tabbar is attached to. These windows share a parent window which doesn't contain any other window. The tabbar window T would have nodelete 'this ... the only way to delete T is via `delete-window' with T as argument or `delete-other-windows' with any but T or W as argument. C-x 1 invoked with either T or W selected will fill the frame with T and W and delete all other windows. C-x 0 in T deletes T but leaves W alone. noresize 'vertical ... means T cannot be resized vertically. nosplit 'parent ... means C-x 2 on T will split the parent window of T and W instead. noother t ... means `other-window' will skip T. There should be a special command to cycle through the attached windows of W and back to W though. But `other-window' and its clients should not try to pick a window like T. The window W would have nodelete 'parent ... means C-x 0 in W will delete both T and W. C-x 1 in W means only W and T will be left on their frame. We could add the twist that on a frame containing W and T only C-x 1 in W deletes T. nosplit 'parent ... is as above. Note that parameter values like 'parent are transitive so you can attach, for example, another window on the left like: ------------------------- | S | T | | |--------------------| | | W | | | | | | | | | | | | | ------------------------- and have C-x 0 in W delete S, T and W (provided there is another window left), C-x 0 in S or T behave as usual, and C-x 1 in S, T or W delete all windows but S, T and W. martin