Re: Adding transient to Emacs core

[Madhu <enometh@meer.net>]

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