Re: Adding transient to Emacs core

[Stefan Monnier]

Madhu [2021-04-27 07:33:17] wrote:
> *  Stefan Monnier <monnier@iro.umontreal.ca> 
> <jwvwnspos54.fsf-monnier+emacs@gnu.org>
> Wrote on Mon, 26 Apr 2021 13:52:49 -0400
>
>>> 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)
>
>> In my experience, among the packages that have to display something
>> (as opposed to your usual major-mode which only provides commands to
>> navigate and edit text), very few correctly deal with all possible
>> `display-buffer-alist` customizations.  The vast majority assumes a
>> single-frame setup and break in random way in less conventional
>> situations.
>>
>> So if transient.el misbehaves in some of those cases, it's in pretty
>> good company.
>
> And I have the option of not being forced to use those packages when
> dealing with emacs.

I'm tempted to guess that you're "young and naïve" because this affects
many core packages that you can't conveniently avoid
(e.g. `read-from-minibuffer` comes to mind).  You just happened not to
bump into those problems because your config is not sufficiently
unusual, or because you find the resulting misbehavior normal.

Admittedly, the situation is a lot better now than back in Emacs-21.

>> In the transient.el API the only thing that could inherently cause
>> problem, AFAICT is the fact that it relies on being able to
>> display a "sizeable" amount of information to the user, but it's hard to
>
> No this is pretty fundamental. The designer of the transient prompt
> can make the prompt big enough to trigger the situations where
> it fails.

Such claims are useless (if not counter productive) without concrete
evidence to back them up.

> (Note I am responding at the same level of generality as your post)

I don't think I can get much more specific about my statement since my
statement is one of absence of problem, for which it's difficult
by nature to provide evidence.

In contrast you claim failure modes, for which you should be able to
provide evidence quite easily.

> If a core package which worked fine is now modified to use a package
> which you introduce and the new package and cannot be used in certain
> circumstances (that the developer of the new package has not or cannot
> consider) I maintain that the new package destroys existing value -
> and if that is the explict intent I hope it is made explicit.

Then I suggest when that happens you report a bug against the change
which made the pre-existing feature start relying on `transient`.

Until that happens, all `transient` does is provide a new functionality
for use in new features, so all you can do is provide evidence that its
design is poor, ideally by providing alternative designs that don't
suffer from the problems you see (of course, you'll first need to
explain what those problems are in order to get some traction).


        Stefan