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 23:11:27 +0200 Message-ID: <87czufcu0w.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> <87bl9z3g95.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17099"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gregory Heytings , Madhu , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 27 23:14:20 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 1lbV2C-0004Is-1H for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 23:14:20 +0200 Original-Received: from localhost ([::1]:38086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbV2A-00056T-Uq for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 17:14:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbUzY-0004Qh-Bd for emacs-devel@gnu.org; Tue, 27 Apr 2021 17:11:36 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:60652) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbUzW-00029F-4S for emacs-devel@gnu.org; Tue, 27 Apr 2021 17:11:36 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id D8480160CB; Tue, 27 Apr 2021 23:11:30 +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=1619557887; bh=9rL8cUWWe7S/+G6tjFWwlNpx Vm5eGxR6FquVk57/XVk=; b=hssTTE2B75v4Ss16pFF34sKAHB7yQsQxf3xlaeGv QA3K+o+Fu+OIncSn6Zfp0yho/+Z634kZJKULYkbwflW+NJkPnU/0/XTDvKFTcjez dyzehyIVTmefzsgLyv4CwnrHzOLKSaEiZ9GnkYv/c3mpNnyeitxHrzhZHryNSvzA L+Y= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id vN6i6Tj3LTms; Tue, 27 Apr 2021 23:11:27 +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 9DFC9160BA; Tue, 27 Apr 2021 23:11:27 +0200 (CEST) In-Reply-To: <87bl9z3g95.fsf@posteo.net> 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:268549 Archived-At: Philip Kaludercic writes: > At the same time it does not seem obvious why, especially with transient > menus that may contain a lot of options (say a ffmpeg interface) > shouldn't be able to use the entire frame. Especially from a user > perspective. It is of course possible that a certain transient menu only features suffix commands that do not care which buffer/window/frame is current. And in the future I might add a feature that would allow the author of such a menu to indicate that that is the case and that the entire frame should be used to display that particular menu. But that a potential new feature and not what we are currently discussing. >> 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. > > What do you mean by "what buffer is the current buffer"? I am somewhat > confused by what you are trying to say here. Would it be less confusing if instead I had said "WHICH buffer is the current buffer"? I don't think I can describe this any better; maybe someone else can. I'm having problems understanding what you find confusing about that paragraph. >> Re-purposing the selected window would massively reduce the usefulness >> of a huge number of commands or even make them completely useless. > > Again, I do not see how this follows? My verison of Magit has > magit-display-buffer-function, that allows me to display the buffer in > the selected window, with no loss of functionality. What does > transient do or need that prevents this? As I have tried (and apparently failed) to explain earlier, it is important to some suffix commands that the same thing is current at the time they are invoked as was current when the menu was entered using the prefix command. This is true regardless of whether Magit-Popup or Transient is used, but these two implementation differ in how they ensure this: - Magit-Popup does it by (1) remembering what buffer is current by recording the current window configuration when the prefix is invoked but before actually displaying the menu in a buffer. Later when the user invokes a suffix, it (2) intercepts that action in order to (3) restore the saved window configuration before (4) actually invoking the suffix command using `call-interactively'. - Transient ensures that the buffer that was current before the menu was displayed, simply by not messing that up in the first place. So yes, Magit-Popup can make the menu buffer the current buffer "with no loss of functionality", but that is only the case because it explicitly makes sure the old window-configuration is restored before it matters. Ultimately it does not matter: everything that is possible with one approach is also possible with the other, but having implemented both, I do have a favorite. It would be useful if users would describe the concrete behaviors that they find undesirable, instead of criticizing implementation details they might not fully understand. There has been a lot of concrete, actionable feedback in the past and I have listened to that and made improvements in response.