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 08:00:37 +0530 Message-ID: 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="35699"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Cancel-Lock: sha1:gk48qGi46R6YSFv4dUA/oh0BMSs= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 04:31:36 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 1lar27-0009DJ-Oc for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 04:31:35 +0200 Original-Received: from localhost ([::1]:47010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lar26-0004v1-Nv for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 22:31:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56644) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lar1J-0004Oh-La for emacs-devel@gnu.org; Sun, 25 Apr 2021 22:30:45 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:50964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lar1I-0007qe-2q for emacs-devel@gnu.org; Sun, 25 Apr 2021 22:30:45 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lar1F-0008Fy-RU for emacs-devel@gnu.org; Mon, 26 Apr 2021 04:30:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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:268445 Archived-At: * Jonas Bernoulli <87czuqi86o.fsf@bernoul.li> : Wrote on Mon, 19 Apr 2021 17:51:43 +0200: > A while go [1] we discussed adding Transient to Emacs core, not just GNU > Elpa. The consensus appeared to be that it should be added to Emacs, so > that other core packages could use it, which I agree with. I would like > to do that now. > > I would prefer to continue maintaining Transient in its current > repository [2] and only import releases into the Emacs repository. > At first I would like to only import "transient.el", later also > "transient.texi". (At this point friendlier documentation is the > area that needs the most work.) > > So what do you think; should be proceed with this? 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. Until these issues are addressed I would prefer that new code in the core not use transient.el - <20190717.093415.1664326708841095012.enometh@meer.net> Hello - some comments on transient.el * c7ad1f01f4ff9e5125bcec99dfb9c3dedadfc369 | Author: Jonas Bernoulli | AuthorDate: Thu May 9 12:25:48 2019 +0200 | |Transient expects the popup buffer to be displayed in a new window. |If that is not the case, then it won't work properly and this commit |does not do anything to make it work properly anyway (because that |is not possible). 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. Transient mode must accomodate this or it must disclaim to emacs support and clearly specify that it is fundamentally incompatible with emacs (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) Effectively the transient abstraction as it stands is incompatible with emacs design and cannot be made to work with it. Besides the new window is not scrollable or searchable, it doesnt support any standard emacs operations. Effectively transient-mdoe destroys the value of any packages written on top of it. |Regardless, the user should still be able to exit the transient state |even when things are broken like that, but doing so failed if the |transient popup was displayed in the only window because we ended up |trying to delete window, which is not allowed. Continue to try to |kill the transient window, but if that fails, then continue with the |rest of the exit procedure. 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)