bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

>  >> Should users really control the dedicatedness of individual
>  >> windows? ECB, for example, uses a quite sophisticated
>  >> approach to control which buffers can be displayed in which windows.
>
>  > BTW, why do you specify "individual" windows here? Did you 
>  > mean something special by that?
> 
> ECB dedicates windows to compiler output, system messages, file lists,
> tags, bookmarks ...  These are windows grouped around an undedicated
> edit area and ECB takes care or assigning buffers to the dedicated
> windows.  ECB doesn't support dedicating "individual" windows 
> within the editor area.

I see. The OP asks how to dedicate windows for the buffers that are in some
mode. You reply that ECB controls which buffers/windows go where and with which
properties (including special/dedicated).

So I guess you are trying to point out a conflict that can arise: in _some_
cases an application might override a user's directive to make some window
dedicated. Is that your point? If so:

1. That's a far cry from claiming that (or asking whether) users are not (or
should never) be able to dedicate windows. Users _can_ dedicate windows, even if
an app can override that.

And that simple user task needs to be better documented. That is the point of
this bug report.

2. There is no real difference between a user and an app. What ECB can do a user
can do, and vice versa. An Emacs "user" can use Lisp (even C) code to do
anything an Emacs library can do. Users _and_ apps can dedicate windows, even if
another app or the user can override that.

So saying that a user might try to dedicate a resource but ECB might override or
prevent that is really no different from saying that the first guy or the last
guy wins when executing code. X does (setq foo 13), but then Y does (setq foo
42).

The important point here is not the subtlety that what a user tries to get s?he
might not always get.  The important point - the point of the bug, is that a
fairly common user task is not adequately documented.

If you want to _also_ add more doc somewhere that clarifies subtleties you are
interested in, go for it.  But first things first.

>  > The OP wants to dedicate all windows for buffers in a certain
>  > mode.
> 
> Suppose you are in a help buffer and want to follow a cross 
> reference to an Elisp source code buffer.  IIRC this usually
> calls `pop-to-buffer'. Now should this action allow `display-buffer'
> to "steal" a window showing another Elisp buffer?

Not sure how that is relevant. Perhaps you are repeating your point above.

Unlike you, I am not trying to redesign Emacs in a bug thread. This bug is about
better documenting for users the _existing_ feature that you _can_ dedicate a
window to a buffer. That's not sufficiently clear in the doc.

Please do not confuse your personal interests and knowledge about this topic
with those of a newbie user. This is not about you or how to best design the
complex interaction of various possibly conflicting directives to Emacs to
display buffers in windows. This is about conveying the simple knowledge that
most non-newbies have about dedicated windows to newbies.

>  > * To dedicate all windows, can't you just
>  >   set `special-display-regexps' to include ".*"?
>  > * To dedicate all windows for buffers in a mode, can't you just
>  >   add ".*" to `special-display-regexps' on the mode hook and
>  >   make the var buffer-local?
>  >
>  > Those both seem to work OK. If you customize 
>  > `emacs-lisp-mode-hook' to add this function, doesn't it DTRT for you?
>  >
>  > (lambda ()
>  >   (make-local-variable 'special-display-regexps)
>  >   (add-to-list 'special-display-regexps ".*"))
> 
> I completely fail to understand how `special-display-regexps' would
> enter here and how it could be used for the OP's purposes.

Does it not do what the OP requested, when you try it? Does it not dedicate the
windows for buffers that are in `emacs-lisp-mode'? Do you "_completely_ fail to
understand" that it does what the OP asked?

Can you create a scenario where it might not work because of some other,
interfering code that has been invoked? No doubt. But that's not the point.

A travel brochure for Haapadapafoo might say "Don't forget to bring your
swimsuit, to enjoy our pristine beaches!", even though it might be the case that
when _you_ happen to visit Haapadapafoo there is an oil spill or a hurricane.

Let's get the simple travel brochure written first, telling potential visitors
what Haapadapafoo generally has to offer (there _is_ a beach there!). You can
write your thesis about hurricane frequency afterward. It will make a lovely
appendix to the brochure and a welcome caveat for naive tourists expecting
guaranteed sunshine.

> Also, making `special-display-regexps' buffer-local doesn't
> make sense to me.  At the time `display-buffer' is called
> _any_ buffer may be current.

So what? Provided that the function that makes the variable local is called when
the correct buffer is current, the variable is made buffer-local in the buffer
in question, i.e. in a buffer in the OP's mode.

Whether that is the right function to use and the hook is run at the proper time
is another question. I think it is, but even if I'm mistaken about that, the
point is that you _can_ make `special-display-regexps' local for a buffer that's
in the mode you want, and doing that will make buffers in that mode display in
dedicated windows.

I do not claim that the function I gave is the right one to document. The point
is that we should document this simple user task - tell users that they _can_ do
it and, if simple, show them _how_ to do it.

> Maybe Stefan can tell us more.  I suppose he's the only one using
> (weakly) dedicated windows in some organized way.

Fine. But please keep in mind the aim of the bug report and, more importantly,
the OP's aim. He wants to have the buffers in mode X use dedicated windows.

Whether that is (a) desirable and (b) possible in _all_ circumstances is another
question. If not, the doc can mention that. If there are important caveats that
users should be aware of, we can mention them.

But the point of the bug is that this basic info - letting users know about
dedicated windows and how they might get the effect desired (at least in most
cases) - that doc is missing/inadequate.

This is not the place to redesign Emacs. If you feel it is important to add more
to the doc to specify nuances, by all means, propose such an addition. But
please do not try to make the perfect into the enemy of the good.

First, let's give users the basic info they need to do what they want. When
that's done, you can add your thesis about cases where subtle or unexpected
interactions might take place.