From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Selecting tooltip frames considered harmful Date: Mon, 26 Feb 2018 19:54:28 +0100 Message-ID: <5A9457E4.9010308@gmx.at> References: <5A9135CE.3020802@gmx.at> <5A9309CB.90404@gmx.at> <5A93CE0D.4050308@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519671212 27456 195.159.176.226 (26 Feb 2018 18:53:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Feb 2018 18:53:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 26 19:53:28 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqNtu-0006bM-J1 for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 19:53:26 +0100 Original-Received: from localhost ([::1]:32799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqNvw-0000cQ-L1 for ged-emacs-devel@m.gmane.org; Mon, 26 Feb 2018 13:55:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqNvB-0000c8-J5 for emacs-devel@gnu.org; Mon, 26 Feb 2018 13:54:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqNv8-0007E9-8S for emacs-devel@gnu.org; Mon, 26 Feb 2018 13:54:45 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:36559) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eqNv7-0007Cv-VU for emacs-devel@gnu.org; Mon, 26 Feb 2018 13:54:42 -0500 Original-Received: from [192.168.1.100] ([46.125.250.72]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MW9TR-1fEoWB3cOf-00XNvL; Mon, 26 Feb 2018 19:54:34 +0100 In-Reply-To: X-Provags-ID: V03:K0:he58KJ4lIZ9THMELCGAy4xzNDwpRCMFP0z9qGCSfHnftZJlMV/k NmUJ/O3GG/ewFDrnDe3DYWWr0MPIlDRNM513OPwILKnDM+AzDymoLJoyWYRW3XCezjdqIsk luLqjAL9Ws2G/O+14N5mbPbEM88EkAAaLfxjtVeUs0iH5tr7zBWc37aIWTaADGtvZHXW9+Q 3LeKirDnxFYK6k5x0yj/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:X+rDryjVSpw=:reThUFMOZR2/0dZFdBHoLn 4UBY4JiiH/6ptgRzUxC3s1FamWMjmQ5Wxr8Bk74KTd78sa6D3KUn8iHAL7gYQFb5/ifs5Nz22 PxgrbtqkeapDa6Tnrs1dlYN2zHedT/MwiLVjTcFyld/9BqjzmUqZcb9xTqq4KIPz9Esn/HwFI U6WfTS+kMNxkEh6lMQ/CUGyO5IhOBvjlB3fZGxSf7bX/lFrIVGE+c/AChhtbqCCnlVYRniv+Z noglgyqiZ1EFY5X+QFceyuxzyY3nBqBrJCW2bYWlhp9LMR9EYVzCIeSitRpFa9qri1darJj1p ktXhVn6S1TOCvsRN29DiviFZUZ8dV3gWt4Q8ENC+DoLS738N+avHibqCFn3Bj9eN+6QGHl/y/ jECid2uK36HjLfwCduCLcFziNtN/363C2jAQf5qm1mxzLxJZQK2wtuKNkWE2omy/HzNAluZqy 8UVWQ6LatE5eWpIUYztKjk/z9B3YgpCno7LUnn2NMUMAo6L6nqdTYQz+IEm26KTYo4MWnATp0 cS55QlmREbXod5yVGh/NmPv9mdJZw+vtdzNmuetvprkV4t+hiSKcuPptUFeBWdBHcVs5QUF4t xVzAWi/rZS/Y9S8Wu/Rx67D+B59VCIpQtosP/GHcptHoee7sbjTqRT4wYF1/h/RalVhNeCKmL PgblOKwbFoLGaa1qyzi4dpuyV1ZUInJ/hAxO/7SBZ5OW1N3jAfcyuhKSXblxL9uv/O1gq4NTr w3uoLifzMay8ovPhnBizUM0s82kKbr7bVOKP3fAbhIrec3M0MJmg2WvfVfRuHgPwl6Yhqcoo X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223081 Archived-At: > the *semantics* should be "the echo area of the window for > which the tooltip frame is transient", I think (and if tip_last_frame > gives us that, then that can be used in the implementation). tip_last_frame should give us that. >> We currently refuse to delete a frame when its minibuffer window >> serves as the minibuffer window of another frame. > > I think this is an accident of implementation, not a feature. > As a user I've found it annoying on a bunch of occasions. > So we don't have to reproduce that misfeature here. > > A more useful behavior would be to allow deleting that frame, and then > next time the other frame needs a miniwindow, you just go "oops, our > miniwindow has been deleted, let's look for another one". > > We could still have a check when deleting a frame to make sure there > remains at least 1 miniwindow somewhere, of course. Using a mechanism similar to that for finding the new 'default-minibuffer-frame' I presume. martin