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.bugs Subject: bug#37840: Missing in the Emacs manuals: Date: Sun, 10 Nov 2019 19:33:17 +0100 Message-ID: <7e6f19a1-fa45-0315-9d22-9bbb7223d695@gmx.at> References: <568AD058-07B1-4C58-81C5-32E2492C1EC5@univie.ac.at> <554177EF-4600-4F68-89F1-3AF67A551F65@univie.ac.at> <438c4dfa-f7c2-5f5e-32bc-eafdd7c33cb7@gmx.at> <3e7f7f10-9151-659b-076d-2bd8ed61d395@gmx.at> <4f7e6535-ac09-bd8c-f3d4-8ae9b4d9d58e@gmx.at> <8736f07hma.fsf@mail.linkov.net> <878sorqrx3.fsf@mail.linkov.net> <7dd1c601-aa2c-8b44-016c-155bdd8a71eb@gmx.at> <6e6cc4e6-277e-1a47-af6c-b7c75301d41e@gmx.at> 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="78592"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37840@debbugs.gnu.org, Juri Linkov To: Konrad Podczeck Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 10 19:34:40 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1iTs2q-000KCr-KZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Nov 2019 19:34:40 +0100 Original-Received: from localhost ([::1]:44608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTs2o-0002Sj-Ng for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Nov 2019 13:34:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60074) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTs2F-0002SY-GJ for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2019 13:34:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTs2E-00047W-Da for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2019 13:34:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iTs2E-00047S-AB for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2019 13:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iTs2E-0008Pr-4h for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2019 13:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2019 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37840 X-GNU-PR-Package: emacs Original-Received: via spool by 37840-submit@debbugs.gnu.org id=B37840.157341081932320 (code B ref 37840); Sun, 10 Nov 2019 18:34:02 +0000 Original-Received: (at 37840) by debbugs.gnu.org; 10 Nov 2019 18:33:39 +0000 Original-Received: from localhost ([127.0.0.1]:52531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTs1r-0008PE-Eu for submit@debbugs.gnu.org; Sun, 10 Nov 2019 13:33:39 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:37723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTs1p-0008P1-By for 37840@debbugs.gnu.org; Sun, 10 Nov 2019 13:33:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573410800; bh=8xajCvNOg9E5WdF4dyv7wiw14wL6EiJyolnteAdfFAg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gejL2XesXNQ3q85Au74W2xrnQWCzU8YntIMDdm1//MB9BtOaLS+MgctMtfnZ5sJg3 RU+Hkp43lvyWZ/BG85om+cCjKMpbPqFx6tVEOOVHZwgINpKntHYvnVCK1v7vtt6BW4 kggPVK2blFi+/zYXgTWpGmSVX+2SxaOotFXIkJkg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.21]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbBu-1hemjp42ek-00sdZY; Sun, 10 Nov 2019 19:33:20 +0100 In-Reply-To: Content-Language: de-AT X-Provags-ID: V03:K1:KsTFHW2p4RVRLQQDk0mkyoxtJe7t4Lhq3m5WyLcQPB+DLA7gzyd RkBdlHDOMDbU/pA5HZG95ae0TgeHaKUbc9vn53S/QxlNajXuPfHNHookXdRyVL7v7Lc322w YJUHANlZSP91v58U907ic8cyPROMISnmSp42V6JxeQB7cxs+aXV6F6Oi2neDr+X98rCGUs+ DS1CBUnhX5lo3uwzN8yYQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:w2GTHpImNow=:fQLogHU5cqswvcb2O47ZwJ WwnWJtEvecMg8hZOlnQHkUtmbq3DS/VtTg8pwcExQDLwaOiPJ61CWt6YoleNHXYRNN+nfrKc2 X0DjUvvMyhQn/o2Gt0iKLBUgbFEhVUuUboc7mS21EJt69qrqSGtajYOL4aG2EBXnogV17xMHO kfKLClGp5/tcM6il02x0JN1UJXsGn6Kx0CO+11R80hW3HdmXK7YW3YL2LvlP6t3Si0XztXu7M z3QuNjnyBeWdW6vX0ASSWfSiY8bi6RaTzFC522KesDqWs1w9Ni4YabGcuw3p5ydI7cQwdiew2 idX0kbRK67iqQpkw1xWtkuoJqIrqb8pbKrzaqTHsuc1hCr/8Ohx5eAKIIsFf9C9ie8dc4a3BO 4aS9eY7qx7/CCuvdKwfcu+D71W8osl4eGJY+wg3TsiF14QduLQvFiITAw7Fq+ARxcgcQHh+0S DxZCDzAs3uaWE9QaXLCdmKk7+de3JT93mP1ml4OnYtTK7tQcQ7q0/4p92e7Em48wxwq97suAo 1fVy+jMRsQ13q1Wpx3AnBzcl2+k6p1/NkWHnr4ghabb9icXQ5HVuUzNZ5AqQMsu6XxE0zors3 maAyTYkCFfK5kyIGsv67NeomxXdkUKNuaNO6pfpQKlTIx3sboMZwNjJzRuloU34dyBoDG/5gQ 5slW9nUTXUh7wYxVutHHU69kvAu2IJ5xjixZDOS0eUT5coCWJmb1Pbhhbaryf5rUZIlGFzmOh lEJxC4+gNeS/HCLyla7FpdLjfnwotFJ0eHtHNCf1HkMBHVJKxWVNwd+d4rRRdluTvgy4+zu5 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:171386 Archived-At: > So what is the correct customization if I wish to have _every_ > buffer in its own (new) frame, just different buffer types having > different frame types, the latter meaning different geometry, fonts > etc.? I'm afraid there's none. The reason is a technical one. The speedbar code uses 'switch-to-buffer' internally to switch to its own buffer in its own window on its own frame. Any customization of 'switch-to-buffer' to do something like switch to _any_ buffer in another frame will make the speedbar choke because its buffer won't be displayed in the same window where it expects it. Note that 'switch-to-buffer-obey-display-actions' is a new addition that has not been yet tested extensively. In earlier versions you had no possibility customizing the behavior of 'switch-to-buffer'. In practice, it always used the selected window for displaying the buffer. You could try to replace the regexp in 'display-buffer-alist' with a function that filters out all buffers that are in a sense special like the speedbar buffer but I'm afraid that you will encounter too many instances of internal uses of 'switch-to-buffer' so you will soon or later get tired of such an approach. The other approach is to specify in that function all buffers that interest you (mostly based on the extension of the file they visit) instead of _every_ buffer. Would that be so difficult? Finally, note that if you make sure that practically all windows you use are strongly dedicated to their buffers, 'switch-to-buffer' calls will respect that. For example, if with emacs -Q I do (custom-set-variables '(display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame) (dedicated . t) (reusable-frames . 0)))) (set-window-dedicated-p nil t) and then choose *Messages* from the Buffers menu, it will pop up in a new frame and the speedbar will work normally. Note, however, that strongly dedicated windows may have other disadvantages you will have to get used to. martin