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.bugs Subject: bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing Date: Thu, 10 Dec 2020 12:52:26 +0100 Message-ID: References: <83eek18ref.fsf@gnu.org> <835z5d8lhc.fsf@gnu.org> <87pn3k87tx.fsf@mail.linkov.net> <877dpqzx3o.fsf@mail.linkov.net> <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> <8f775254-65d2-6f3d-4c71-b6f10bb2b278@gmx.at> 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="30918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , larsi@gnus.org, 45072@debbugs.gnu.org To: Jean Louis Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 13:22:44 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1knKy4-0007uw-7t for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 13:22:44 +0100 Original-Received: from localhost ([::1]:37476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knKy3-000571-6G for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 07:22:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knKWI-0007Kg-Iv for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 06:54:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53835) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knKWI-0000Uf-9g for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 06:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knKWI-0007vi-7J for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 06:54: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: Thu, 10 Dec 2020 11:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45072 X-GNU-PR-Package: emacs Original-Received: via spool by 45072-submit@debbugs.gnu.org id=B45072.160760118730404 (code B ref 45072); Thu, 10 Dec 2020 11:54:02 +0000 Original-Received: (at 45072) by debbugs.gnu.org; 10 Dec 2020 11:53:07 +0000 Original-Received: from localhost ([127.0.0.1]:37145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knKVP-0007uJ-1e for submit@debbugs.gnu.org; Thu, 10 Dec 2020 06:53:07 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:38111) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knKVN-0007tp-F6 for 45072@debbugs.gnu.org; Thu, 10 Dec 2020 06:53:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1607601147; bh=LksnQepJDH9Gbvx7vTSQ/21N/XdmJyY5Yxj+tTTFwg8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=MmxA2EDYQYrMaUovoQAibeHFcGY+Eg0gA+BOwDsN5nZkE65KlbLPrAJ25w9GUjNiM l2vxQS29hQWHnZk9S58TnOEWa+jP6Q3qcZcf43/RP572ThGhKNfDBlWb27rE/TDk0w 0D1JIw4hL5dfOBqWh0w4jOTqk01Bfb3t9E0uqg9U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.249]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MA7Ka-1kxno91Fzm-00BZi3; Thu, 10 Dec 2020 12:52:27 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:TIrC625Dn+EJg/rjf8CZ8kKW3PogT3EE+0V8cqXR8PYeVMcj92c gcDCrcyDLX58XMcNTlr4msCFXrlWSsS54/gXJf1DM0+r60ShdnwwANQqzJ8OHAqiRFJIWyC /9NT0tos1asojU89NfPb8tSZrumjro8JeVtcmEzWmpChrse8eluugqL6s4ZuAd74Zk7wBK6 jEAhdmgUfPyu4jjYxFCIQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:9Z3ZARewYvE=:XS4qld8Ufm+7dmNiRl7kbl yb8PBG9lOvZ+cWXGqSNeiF1ZrlAq0F/d/pa7Xb41vJooZQisHHR/NgVBbIRdNkCDLnNdNi4qs 6F3IkOa20QmmJBEEBAsapASTqLjQiCUu1wjm72OgoiitgvmRX0YZ6YOTorEDTs4ntAJcmUQMt VnVlc+lHeJWnZXPyp7H7haN6RZeqAcQgOgvSDgLEhG7H4x3q+8/S/bP/sf1CXwYM65/4i3F5K lXExtN3wMKT1BKxHcD0CI+VU6ALQJDThsH1CzHQex+4QDUn9E8/FOh/YJfjoXIU/EmrTaL6Oq s1YW82brQ4sYspRpBpn6/XVZoIiHDVdkiO5kgVShxHMO471zoYzx8aYSccTAaG3Dlo9Htifa6 eEfYrsc8hBprtLoZfA3xRZiDvCwDRhjlF8c41kZ/+JvSB0GNVPFZ5j4SS0lp0Y8x6Cxepjjon x71XXzh5r9zrNki953gd7wMEZHne2lqggyBFJxqU0tVcZJUuf2x1hNRaOdHEWv9JyZ70LsTCi r/q9PnGKmGsxtjCnsc/jiEQv+H5pnQ2Q/etcWSEM0Dik9qL/aZ51Eu7a9P8valKVzlg7qewwd tn/E232DWMoTyl8zyx6HNmF8riKTQFhAXidZHh1Kofv1x41hzdK7NVJRyg7sqQ7j356dvL9cd cLTFiujLkDYn8QrtwxK7yS6X2KL3QhV8UqBRIMS6PrmN8AS6Yrm9DdqKLR/m6RICZoZ1X65R0 xfyRVbpI5Hjv858+RWKLWnP77PatnAsHeLbHSCsHunmxWS0I7KTbWpfMAp1E2UZK61hJYt4C X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195643 Archived-At: >> All these scenarios are with customizations. I'm not experienced enough >> to tell whether they (can) happen in practice. > > Do you refer to standard completion in minibuffer that it may be > customized to replace a present window with the completion instead of > opening new windows? > > That would be nice as I would like to avoid those jerks when there are > 2 horizontal windows and then third one appears for completion jerking > both of them up and narrowing those visible windows to almost > invisible rendering both of them unusable. Doesn't it do that already? Note that here and elsewhere I'm purely speculating how application writers and users might tweak things. > In that case I would find it useful if the bottom window is > temporarily replaced with the completion, without opening the new > window for completion. If that would be the case then restoring > previous buffer that was there before replacement of window would be > necessary and useful. > > My complain came from those buffers changed by me, user, to something > else, that completion never even tackled. I have not even use > completion, just minibuffer, and above 2 horizontal windows get > restored even though I have not wanted it. By switching to other > buffer in those windows user said "I need that other buffer". These should be already addressed by my earlier patch. But Juri meant that we have to handle completions windows separately since otherwise they may persist. > But if the window is replaced with completion, I do not have any > window where I would switch the buffer. Or maybe it also works that > completion window is switched to something else. Labyrinth. > > Do you know how to make such setting to open up completion list in > such way to replace the bottom window instead of poping up with new > window? > > I cannot find any variable completion*wind I hope Juri can. martin