Re: Pretest begins end-June

[martin rudalics]

> You said that binding the var would no longer work.
> That is a removal/limit of that possibility.

The application can bind the variable `display-buffer-alist' instead.

> And you do not provide a suitable alternative.  You are missing/ignoring the
> general case, where the code that does the display is not necessarily 
available
> to modify textually.

I don't understand you here.

> Your "suitable alternative" is workable only in the minority of cases where 
the
> call to `pop-to-buffer' is directly available and can be edited.  You propose
> source-code editing as a replacement for the programmatic control of dynamic
> binding.

Actually I followed Stefan's advice which I repeat here once more:

  Rather than let-binding some Lisp-manipulated "config" var, I was
  thinking of passing special parameters to display-buffer (I'd rather
  avoid dynamic scoping whenever possible).

So you can see that my first approach was to use conventional binding.

>> IMHO an application may request (or better "suggest")
>> specific behavior and set private variables.
>
> Your example substitute code does not "request" or "suggest" how to display,
> IIUC.  It imposes how to display, the same as the code it would replace.

But not by manipulating a user option.  Moreover, users can _always_
override the application, if they want to.

> Or if not, then it is not at all a suitable alternative and we are not even
> talking apples and oranges but rather apples and orangutans.
>
>> But it should not change or rebind any user option.
>
> Obviously I disagree.  You're apparently OK with an application deciding 
whether
> to pop up a frame, but not OK with doing that by binding a dynamic variable,
> because in this case the var is a user option.

Yes (if we replace the term "deciding" by the term "suggesting").

> That's hypocritical and silly.  If an application controls the display, then 
it
> has taken control for that away from the user, regardless of how it does so.

No.  A let-binding affects every `display-buffer' call nested in it.  An
argument affects only the associated call.

> Bypassing `pop-up-frames' to do that is no more respectful of the user's 
general
> preference as expressed by that var than is binding the var.  What is 
important
> are the resulting behavior and the user's preferences.
>
> Sometimes an application can be right to decide how something is displayed, in
> spite of a user's general preference.  Developers need to DTRT, thinking about
> the user and her preferences to decide what TRT is in any given context.
> Respecting users does not necessarily mean blindly applying their general
> preferences in all contexts.

Let's agree that developers and users may be both wrong, sometimes.

> If your code violates a user's general preference as defined by her
> `pop-up-frames' value, it is irrelevant how that violation was implemented.
>
> And this is more general than a question about user options.  It is about
> dynamic variables in general.  Removing the ability to bind a dynamic var in
> order to control behavior in code that is not directly modifiable is limiting
> and, frankly, unlispy.  (No flames about lexical-only Lisps, please.)

We wouldn't agree anyway.

martin