|
From: | Jean Louis |
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 15:07:42 +0300 |
User-agent: | Mutt/2.0 (3d08634) (2020-11-07) |
* martin rudalics <rudalics@gmx.at> [2020-12-10 14:52]: > >> 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. That is what I am pointing to, it does not do that what you described, so descriptions misses the point. They don't apply. When I have this window: +---------------------+ | | | | | | | | +---------------------+ | | | | | | | | |---------------------| +--------------------+ Then upon completion it becomes this: +---------------------+ | | +---------------------+ | | +---------------------+ | | | completion here | | | | | | | | | |---------------------| +---------------------+ So the third window appears there. It is not replacement. I would rather prefer replacement than third window jerking other two up and rendering them not usable. But that is not subject of this bug report. > 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. Thank you, I will try but not ready. My version is days old, need to upgrade to new version to test the patch.
[Prev in Thread] | Current Thread | [Next in Thread] |