bug#8856: 24.0.50; regression: special-display-frame is no longer dedicated

[Drew Adams]

>  > Please run Emacs this way for testing this, so we're on 
>  > the same page.
> 
> I know what the bug is now.  The old code ran some very complicated
> raise-frame mechanism but did _not_ select the window if it already
> existed on another frame.  That's what I changed in the new 
> code to make it uniform with the pop-up-a-new-frame behavior.  
> Apparently that was a bad idea.  I now (hopefully) reverted the
> old behavior.
> 
> Attached find the latest window.el.  It only works with the latest two
> versions uploaded by Sean.  If you get any warnings or bugs 
> when loading or compiling it please tell me.

I'll give it a try and let you knonw.  Thanks for struggling with all of this,
and for trying to improve the handling of windows and frames - a daunting task,
no doubt.

> Also, `display-buffer-alist' will unlikely work with your code
> yet.  So you need to trigger 1on1 using the old options.

I'm not sure what you mean, in particular by the last sentence.  Are you
referring to how command `1on1-emacs' is invoked or to something else?

I assume that I would at least need to replace the assignment, in `1on1-emacs',
of `pop-up-frames' to `t' by something else, presumably something involving
`display-buffer-alist'.

Are you saying that there is not yet any good replacement in this case?  Will
you let me know when you have an idea what I can do, to DTRT, once the "yet" is
dealt with?

> Redirecting frame focus is not very easy to handle :-(

I am sure of that.  And most users have nil `pop-up-frames' (or equivalent), and
they never have to deal with focus redirection.  Likewise most Emacs
maintainers.

I've been trying to get Emacs Dev to think (and test!) more in terms of frames
for years.  Frames are nearly second-class citizens for Emacs.  Development and
maintenance changes have often, I think, been tested only with `pop-up-frames' =
nil.  Certainly they are more tested in that case than in the non-nil case.
Frames are almost an afterthought.

Partly this is no doubt due to frames being handled differently by different
window mgrs.  Partly it may be due to habit (Emacs had windows before frames,
most users do not use non-nil `pop-up-frames', etc.).

--

BTW, as you might have noticed in looking at command `1on1-emacs' and
`oneonone.el' generally, it presents an example of why it is wrong to think that
code should never bind or set user options.  I mention this because (you think
that) you disagree.

Emacs base code should not overrule user settings, of course.  But code that is
invoked by user choice is another story.  A user chooses to invoke a command,
just as s?he chooses option settings and other default values.

It is helpful for the command's doc in this case to mention that it temporarily
binds such-and-such user option to such-and-such value or that it sets the
option (i.e. not just temporarily), etc.

But there is no reason that a voluntarily invoked command should not alter a
user setting.  The moral obligation is to let users know just what the
consequences of invocation are, including option changes.  A user of command
`1on1-emacs' should know that it sets `pop-up-frames' to t, and that that is
precisely part of the command's raison d'etre.  You use `1on1-emacs' only if you
want non-nil `pop-up-frames'.

Emacs has always allowed for and even provided option-altering commands.  See
`customize-set-variable', `customize-set-value', and `set-variable', for
instance.

Personally, although I try to convince users to use Customize rather than just
Lisp code, I also believe it is helpful to go beyond Customize as an interactive
way to modify options and faces.

I've done that with Do Re Mi, for instance: provide commands to easily modify
option values incrementally.  Nothing wrong with that - in fact, we could use
more of it.  Nothing should limit us to the Customize UI as the only way to
interactively change user settings.