From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Adding transient to Emacs core Date: Tue, 27 Apr 2021 17:24:56 +0200 Message-ID: <87fszbda2f.fsf@bernoul.li> References: <87czuqi86o.fsf@bernoul.li> <87pmyhdvla.fsf@bernoul.li> <20210426.230318.88708181443886760.enometh@meer.net> <878s54m7ae.fsf@bernoul.li> <875z08lyoz.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28504"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Madhu , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 27 17:29:47 2021 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 1lbPek-0007Lb-Cv for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 17:29:46 +0200 Original-Received: from localhost ([::1]:33868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbPeh-0004xm-KF for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 11:29:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbPaD-0002d5-LN for emacs-devel@gnu.org; Tue, 27 Apr 2021 11:25:05 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:36418) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbPaB-0007pa-Jy for emacs-devel@gnu.org; Tue, 27 Apr 2021 11:25:05 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id C35AD16645; Tue, 27 Apr 2021 17:25:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1619537098; bh=n133KmVnP50zBDnMv/W+Zfyc zd3rNybEnteeu3IHdhI=; b=tpnONuOnnvxj4md20HQJtDrENTg02k+35+2Ay54j O9IhXWRUEC1a3BbzNOhaiVNqWudbmZNsKAyhl7XJGvGrj7gKDM4GiGBssWUwgAfM R5qam3P6CI90No4lcZ72kp2D2fj7Tb/VejhurJCsNlp8/C/ZTZTeaMGJbe7v6ZZu jYk= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id GXTArxIxgsTC; Tue, 27 Apr 2021 17:24:58 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 8F7F7165F2; Tue, 27 Apr 2021 17:24:58 +0200 (CEST) In-Reply-To: Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:268534 Archived-At: Gregory Heytings writes: >> >> If the selected window were repurposed to display transient's buffer, >> then that would change what buffer is the current buffer and it would >> become impossible to act on the buffer that was previously the current >> buffer or on "the thing under the cursor" in that buffer. >> > > Yes, I understand this, but when the frame is too small to display both > the current window and the transient buffer window, would it not be better > to do that anyway, and to restore the previously current buffer before > executing the command? I guess it is a matter of preference. This is the default value of `transient-display-buffer-action: (display-buffer-in-side-window (side . bottom) (inhibit-same-window . t)) The (inhibit-same-window . t) is there to *prevent* it from falling back to that behavior. One way of dealing with the fact that different people want different fallback behavior in this case would be to add a note about this to the doc-string. Another possible fallback would be to not display the popup buffer at all when the selected frame isn't high enough and to instead display a message in the echo area about what the issue is, while still allowing the user to invoke suffix commands. All of this will require some thought and experimentation. Please share yours and give me the time I need to try things out.