From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: master 18b680cfd1: Fix bug#52467 by adding a new custom variable 'display-comint-buffer-action' Date: Sun, 2 Jan 2022 19:40:45 +0100 Message-ID: <9d5f512f-dd10-fb6b-2fe7-db24ed92f7c8@gmx.at> References: <164073060906.21430.4993248796177370312@vcs2.savannah.gnu.org> <20211228223009.6D0BAC002EE@vcs2.savannah.gnu.org> <871r1v8nhf.fsf@gnus.org> <83ilv7jqm7.fsf@gnu.org> <6a9cd581-1630-4a95-62c4-419603561072@gmx.at> <3499cedf-b170-3045-873d-d45d2972ae13@gmx.at> <0f492ac4-4167-5448-2c74-a5f67950eae4@yandex.ru> <2de2323b-6d34-9263-776b-dbeff036f8f4@gmx.at> <87zgog68ni.fsf@gnus.org> <8dfc6f22-d331-e7c1-b536-2d374197528f@gmx.at> <86v8z26o15.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel@gnu.org, Eli Zaretskii , sdsg@amazon.com, Dmitry Gutov To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 02 19:44:14 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n45q2-0007xf-NR for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 19:44:14 +0100 Original-Received: from localhost ([::1]:50468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n45q1-00038S-9B for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 13:44:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55232) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n45mo-0001nz-9I for emacs-devel@gnu.org; Sun, 02 Jan 2022 13:40:54 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:49937) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n45mm-0007lq-CM; Sun, 02 Jan 2022 13:40:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1641148847; bh=/u2oYssDAnS2IDJsJeM/HuZ5G8DQFZ70UKVZq1hl+a8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=XJEGXFJQesAQkLPNRXDIEqyEehyq/1vBkivx0ro6byqc/XGl3RmyuTN9KPkxfEKiF PHS+Fk6+Y7cJBYBViKZCeWbmMXY75GgAQx/Hw4ZgSBptb1iw0vJfzaBIANlnl9q2OD m91jfS/G+zU0h5G+is/Zzz0rxqVRWOlGl8ro1J0M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.26]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MjS9C-1mgHXo3nre-00kuEZ; Sun, 02 Jan 2022 19:40:47 +0100 In-Reply-To: <86v8z26o15.fsf@mail.linkov.net> Content-Language: en-US X-Provags-ID: V03:K1:Xuc8P0wvJC0cHC4Y3O6b4TdsnPIGLqCnDCKm31CBUR9qe+yVfW8 4qhjIdl0+vYu5FKUBMAIY2fpQmlurZs6MrOMGKt2RCRGjIrXIQpeF8FeLa2ZqBXCmimdSx+ lR0FrgFwUTihFvdLVqo2rOM3ZLh/s4uYFm5HZw3VGBYqPvuOkT4bNrwNTsBCXJzvXSIXjpl oMoaGxNl4pAu99Xd9w1sQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:fo7gf1Dp9KA=:9uNxAVBG49L3V2Ne8Rhavm /AdiibZ6cUZ1hviqy82DFxBrqKX9UyWfBfwjA2NbUz27S6MkVFaMwLtwysuRenvKl+haMXbeq pYzPZKoiAxWeoC+skpQ4galGWOIp0zBfjJmipDdT8n1EmS18JaToc0md9xd2/FBt7egzYgujd 1GMwmvNACkjjz3Xe+86GyxDF9j+4epEuQvwsEKLH0PcLtPV4kfdBceAolMgF59tBYv6lP47d5 WS5QFCib2EB3DSOvJWbZgIjevvVGSeq2hgpVUDT8Xkg/frGLs1L7eRMUXh1KTGTxhekVsSNlt FHdkwu9kXB4CKemXEOA2bvwZbok8eZF6DApGZ4MwdlflDnoKT5iRzA0fV4vZoQwQ5pU2y5W2V eiZ9li0LjJX7KK17FHfzmBobmg5dMvoXnUNt1ThxpVfYyv87MaipspUUmAKmHpODicxtmLOsp ZYnw3viws3if7sSzVWcPZ0DwKVJ0wLPMzSO2BvG8GzkV2Kur9XbunZ5gmmfJhv8Bmli5iYDGA zt224w4c6SybVgJfNan9b9lt/wpNIn781HJajwh6VpNlO2NB0Y2KHolmQ3Shm0Lh9gXjdbs4U RF7obLIsFHfdL8sA/ySZBgQH5WM4F+WnoSjHOXSBsAq8QXk4K6g9Bxs7SlWsaywXa98/176rV BiPa0i539vNrPk7xgUM8HmxzWGKZPZM2UZsD5JFSUzDYVC3X2TeJfjPZWeVnQ82jJSUrwv96Q 0jNno/EDgLtct66RKa6/cEb/5X8W1W4SYzTVdJJoJe2bY8ywYVlUNXLdiivhNmwj5b4nkZ32 Received-SPF: pass client-ip=212.227.17.20; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283948 Archived-At: > This is how we can make customization simpler, helping to get the old behavior > back for a set of commands. Currently there are 11 comint commands that > have invocations like: > > (pop-to-buffer "*inferior-lisp*" display-comint-buffer-action) > (pop-to-buffer "*scheme*" display-comint-buffer-action) > ... IIUC 'shell' still has (pop-to-buffer buffer), 'sh-show-shell' has (pop-to-buffer (process-buffer (sh-shell-process t))). Shouldn't these become part of the same scheme? > To change their behavior at once the user needs to construct > a complex regexp that matches all used comint buffer names, > > "\\*inferior-lisp\\*\\|\\*scheme\\*\\|..." > > This is completely unmanageable. *eshell*<1>, *eshell*<2> ... come to mind. > Instead of this, all calls could add > a special tag: > > (pop-to-buffer "*inferior-lisp*" '(nil (comint . t))) > > Then a condition predicate could check for this tag: > > (defun display-buffer-comint (buffer-name action) > (assq 'comint action)) > > and the user can customize all comint commands with: > > (add-to-list 'display-buffer-alist > '(display-buffer-comint > (display-buffer-same-window > . ((reusable-frames . 0) > (inhibit-same-window . nil))))) If we do that we should first make a list of possible tags like 'occur' or 'info' and check whether we should provide similar functions for them too. Yet the problem remains how to easily get back the old behavior for individual 'display-buffer'-based calls we decided to change. martin