Re: Adding transient to Emacs core

[Madhu]

* 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 <jonas@bernoul.li>
| 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)