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: Mon, 26 Apr 2021 15:27:45 +0200 Message-ID: <87pmyhdvla.fsf@bernoul.li> References: <87czuqi86o.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="18664"; mail-complaints-to="usenet@ciao.gmane.io" To: Madhu , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 15:32:16 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 1lb1LT-0004ay-G4 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 15:32:15 +0200 Original-Received: from localhost ([::1]:35564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lb1LS-0004pK-DC for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 09:32:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb1HT-0002Sl-6W for emacs-devel@gnu.org; Mon, 26 Apr 2021 09:28:07 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:35466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb1HL-00089C-Fl for emacs-devel@gnu.org; Mon, 26 Apr 2021 09:28:06 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 9A0A916616; Mon, 26 Apr 2021 15:27:49 +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=1619443667; bh=DbrpUYkGmMY4GsaopTjqduah b6pefWP9z2XKkf52aK4=; b=1ROv4Iv2W6hy4sqQmmsdGJ2htEQt4Oco/558t4+K uQa3znZ7gnvSUzde4WdRbmXOmrsfMIis+IW32LyvIkapFcmCx9Aq3kOGfJ8ykBCT 2aOioczXBv4LGeVr4FDmMH1f1lFtOVm90Bn/uov0W39b5LGJBbv9fl3e7y5LbSn5 5lw= 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 VIpH347blmKh; Mon, 26 Apr 2021 15:27:47 +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 6A3DD165B5; Mon, 26 Apr 2021 15:27:47 +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_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01 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:268469 Archived-At: Madhu writes: > I think transient.el has serious design problems with respect to emacs. > > I had sent the following to jonas back in 2019, and got a response > asking me to open a github account - which I did not have at that > time. What bothered me more than the fact that you contacted my privately, is the wording of your communication, the highlight being: > Effectively transient-mdoe destroys the value of any packages written > on top of it. I have replied to your mail by asking you to refrain from remarks like this and that you communicate publicly. I requested the latter in the hope that that would help with the former. It is disappointing that you ignore that request to refrain from such hyperbole and instead copy your original message verbatim. (Except for the weird preface "[private mail please do not respool on google/public servers]"). Just re-sending a mail from two years ago also means that it ignores all technical improvements since than. > Besides the new window is not scrollable or searchable, it doesnt > support any standard emacs operations. No longer true, but you have to explicitly enable it with: (setq transient-enable-popup-navigation t) > with-demoted-errors does not always work in killing off the new frame, > and emacs gets into a generally irrecoverable state (unless you have > taken precautions after having studied the transient.el's failure > modes before) This no longer happens. I have figured out the last remaining heisenbug that could put Emacs in an inconsistent state months ago and there have been zero new reports since then. The error handling also has improved substantially, so even if something does go spectacularly wrong, this should no longer put Emacs in an inconsistent state. > This design leads to spectacular failure modes with emacs and does not > really close issue #44. The assumption in transient's code is that > display-buffer-in-side-window will always succeed but that is not how > display-buffer is specified to work: > > If a window cannot be popped up in the current frame display-buffer > will create a new frame. There is room for improvement, but the current worst case scenario is the following. Note that this can only happen if the current frame is (1) less than ~5 lines high, (2) no other frame already exists, and (3) the window manager selects the newly created frame. In that case a new frame briefly flashes and disappears again. I.e. it is impossible to invoke the suffixes of that transient prefix command, but Emacs does not enter any "spectacular failure modes" (no transient keymaps and/or hooks get stuck). You can simply increase the frame size and then invoke the transient prefix again. Fixing this remaining issue might be as easy as: (define-key transient-predicate-map [handle-switch-frame] 'transient--do-stay) This is not the default yet but I might do this or something similar in the near future. This also makes it possible to: (setq transient-display-buffer-action '(display-buffer-pop-up-frame)) And even without that there were several alternative display actions available that work just fine, e.g.: (setq transient-display-buffer-action '(display-buffer-in-child-frame)) (setq transient-display-buffer-action '(display-buffer-below-selected)) > (since you are using display-buffer to display this pop-up window you > are effectively supporting user customization of display-buffer. In > which case you should not use display-buffer at all since you cannot > support legitimate use of display-buffer) Yes, transient does not support every conceivable display action, but neither does anything else. What you are saying here is "you don't support all possible customizations, therefore you should offer none". Jonas