From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: Adding transient to Emacs core Date: Mon, 26 Apr 2021 23:03:18 +0530 (IST) Message-ID: <20210426.230318.88708181443886760.enometh@meer.net> References: <87czuqi86o.fsf@bernoul.li> <87pmyhdvla.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10483"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: jonas@bernoul.li Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 19:35:22 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 1lb58j-0002NQ-RT for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 19:35:21 +0200 Original-Received: from localhost ([::1]:36108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lb58i-0006oq-U9 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 13:35:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb57H-0005Vp-5a for emacs-devel@gnu.org; Mon, 26 Apr 2021 13:33:51 -0400 Original-Received: from smtp6.ctinetworks.com ([205.166.61.199]:55192) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb57A-0001xX-IY for emacs-devel@gnu.org; Mon, 26 Apr 2021 13:33:46 -0400 Original-Received: from localhost (unknown [117.193.4.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp6.ctinetworks.com (Postfix) with ESMTPSA id 405448515F; Mon, 26 Apr 2021 13:33:27 -0400 (EDT) In-Reply-To: <87pmyhdvla.fsf@bernoul.li> X-Mailer: Mew version 6.8 on Emacs 28.0 X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 405448515F.A5E89 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-Watermark: 1620322415.30699@+vMa1t1sRn8iZi42Vbh5YQ Received-SPF: pass client-ip=205.166.61.199; envelope-from=enometh@meer.net; helo=smtp6.ctinetworks.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:268496 Archived-At: * Jonas Bernoulli <87pmyhdvla.fsf@bernoul.li> Wrote on Mon, 26 Apr 2021 15:27:45 +0200 > 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. [I apologize - I wasn't sensitized enough to your sensibilities.] > Just re-sending a mail from two years ago also means that it ignores > all technical improvements since than. This may be true: the version I was using was a commit from June 2020. >> 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. I assume this is on the current `master' branch - and will be using this shortly. >> 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. (setq pop-up-windows nil) is a valid setting. The spectacular scenarios I've encountered are when the frame did *not* go away - and you cannot or control emacs and have to switch to a different terminal and kill it. I hope you understand the inconvenience that this sort of situation causes. I understans that you say this has been addressed. > 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". If you say that (pop-up-windows nil) is not a valid customization, I would strongly disagree with that. If transient cannot handle input for some configuration then there should be a fallback to emacs mechanisms that *can* handle input. If the package does not support use display-buffer according to the design of display-buffer, I maintain it will have a negative impact if adopted in the core and one is constrained to use it (instead of keeping it optional)