Re: Adding transient to Emacs core

[Jonas Bernoulli <jonas@bernoul.li>]

Madhu <enometh@meer.net> 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