bug#6280: 24.0.50; (elisp) Dedicated Windows

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

A user just asked on help-gnu-emacs for a "way to specify that windows
containing buffers which have a certain mode should *never* be reused or
closed unless specifically by user action (for example visiting a new
file from the window)". This info is not readily available, but it
should be.
 
The doc about dedicated windows is missing a few things.
 
1. There should be something in the Emacs manual about how to make
windows be dedicated - esp. by default. There is nothing in the manual
about it AFAICT. The closest thing is node `Special Buffer Frames'.
 
[The node name is a misnomer, BTW: it should be `Special-Buffer Frames'
or `Frames for Special Buffers'.  It is the buffers that are special
buffers, not "buffer frames" that are special.]
 
2. In the Elisp manual, the node `Dedicated Windows' would presumably
cover this topic, but there is no real mention there of special-display
stuff, which is the way a user will typically try to make windows in
general dedicated.  There is a link to the node `Choosing Window', but
it is not obvious that that is the link to follow to get the relevant
info.  It simply says "`display-buffer' (*note Choosing Window::) never
uses a dedicated window for displaying another buffer in it."
 
Please present the topic of dedicated windows in a way that is more
useful to users such as the OP in help-gnu-emacs.  Provide, for
instance:
 
* a simple recipe for making all windows dedicated and
 
* a simple recipe for making all windows for buffers in a certain mode
dedicated

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-05-23 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'
 

bug#6280: 24.0.50; (elisp) Dedicated Windows

[martin rudalics]

 > Please present the topic of dedicated windows in a way that is more
 > useful to users such as the OP in help-gnu-emacs.

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.

 > Provide, for
 > instance:
 >
 > * a simple recipe for making all windows dedicated and
 >
 > * a simple recipe for making all windows for buffers in a certain mode
 > dedicated

There is none.  Any function accomplishing such a thing would have to be
run by `window-configuration-change-hook'.

martin

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

>  > Please present the topic of dedicated windows in a way that is more
>  > useful to users such as the OP in help-gnu-emacs.
> 
> Should users really control the dedicatedness of individual windows?

Questions that start "Should users really control" are anti-GNU/Emacs. (Only
half-kidding.) Users are not losers.

FYI, here is what the OP on help-gnu-emacs said, before his technical request:

OP> I swear, if emacs "steals" a window to reuse for
OP> something else again, I'm going to swing an axe at it.

IMO, users should be able to make windows dedicated.
And they are able to, AFAICT.

BTW, why do you specify "individual" windows here? Did you mean something
special by that? The OP wants to dedicate all windows for buffers in a certain
mode.

> ECB, for example, uses a quite sophisticated approach to control which
> buffers can be displayed in which windows.
> 
>  > Provide, for instance:
>  >
>  > * a simple recipe for making all windows dedicated and
>  > * a simple recipe for making all windows for buffers in a 
>  >   certain mode dedicated
> 
> There is none.  Any function accomplishing such a thing would 
> have to be run by `window-configuration-change-hook'.

* 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 ".*"))

bug#6280: 24.0.50; (elisp) Dedicated Windows

[martin rudalics]

 >> Should users really control the dedicatedness of individual windows?
 >
 > Questions that start "Should users really control" are anti-GNU/Emacs. (Only
 > half-kidding.) Users are not losers.

Emacs is free software.  I don't intend to control each and every aspect
of it.

 > FYI, here is what the OP on help-gnu-emacs said, before his technical request:
 >
 > OP> I swear, if emacs "steals" a window to reuse for
 > OP> something else again, I'm going to swing an axe at it.

I doubt that would help much.

 > IMO, users should be able to make windows dedicated.
 > And they are able to, AFAICT.
 >
 > 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.

 > 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?

 > * 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.  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.

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

martin

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.

bug#6280: 24.0.50; (elisp) Dedicated Windows

[martin rudalics]

 > 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?

No, and I even don't have a point here.  I just wanted to explain how
ECB handles what might be the OP's dilemma.

 > If so:
 >
[...]
 > And that simple user task needs to be better documented.

I doubt that this is a simple user task ...

 >  The important point - the point of the bug, is that a
 > fairly common user task is not adequately documented.

... or a fairly common one.

 >> 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.

No.  I tried to give a simple example demonstrating that handling
dedicated windows is not simple.

 > 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.

Dedicated windows have an entire section in the Elisp manual.  What is
not sufficiently clear there?

 > 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.

We have to disagree on one simple fact: You consider dedicating windows
to buffers a simple task that requires only simple knowledge.  I don't.

 > 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?

Suppose I have a window showing a buffer in `emacs-lisp-mode' and I
split that window.  Then the new window obviosuly should be dedicated to
that buffer as well.  I fail to understand how you achieve that.

 >> 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.

The fact that you can make a variable buffer-local doesn't imply that it
makes sense to do so.  Making `special-display-regexps' buffer-local
doesn't make sense, IMHO.

 > 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.
[...]
 > 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.

I earlier mentioned how you can do what the OP wants.  Write a function
that you _globally_ add to `window-configuration-change-hook'.  That
function would have to scan `window-list', check for each window whether
its buffer is in a mode that shall have dedicated windows, and, if that
is the case, call `set-window-dedicated-p' for that window with some
non-nil, non-t flag.  If someone can come up with a simpler solution
I'll be all ears.

martin

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

Martin, you are trying to take this bug report far afield.
I won't bother to get into it with you.

I was clear about what is needed for the doc about this topic:

1. Put something in the Emacs manual about how to make windows dedicated.
2. In the Elisp manual, mention `special-display' buffers in node `Dedicated
Windows'.

See the original bug report for details.


When you say things like this, you seem to be playing provocateur:

> Suppose I have a window showing a buffer in `emacs-lisp-mode' and I
> split that window.  Then the new window obviosuly should be 
> dedicated to that buffer as well.  I fail to understand how you achieve that.

My value of `special-display-regexps' is ("[ ]?[*][^*]+[*]"), so buffers named
`*...*' are special.  That means that most of the time they are in dedicated
windows.

Can I split a `*Help*' window or an `*Info*' window?  Of course.  Is each of the
two windows dedicated to the buffer?  No, only the first (original) one is.  So
what?

Do you want to change all of the doc about special buffers, to make your point?
The doc string of `special-display-regexps' is technically incorrect/incomplete,
since it suggests that displaying such a buffer (with the default
`special-display-function') gives it its own frame.

Should we add a note here, there, and everywhere saying "Martin wants you to
know that this is not strictly true in all cases. Here is the truth (fasten your
seat belt and shoulder harness): ... [3 pages of details about the true
relations between windows and buffers]"?
[** - see below]

This is all beside the point.  What is important is that knowing about the
existence of `special-display-regexps' I am able to have Emacs open such buffers
in their own window and inhibit their replacement in that window.  It is that
knowledge that needs to be better communicated to users.  That's all.

You are up on your soap box and totally missing the point.  It's about the doc.
It's about new users.  It's about making it more obvious that you can dedicate
windows to buffers, that there is a notion of special buffer.  This is not about
the intricacies of special-buffer display.

> I earlier mentioned how you can do what the OP wants.  Write 
> a function that you _globally_ add to
> `window-configuration-change-hook'.  That function would have to
> scan `window-list', check for each window whether
> its buffer is in a mode that shall have dedicated windows,
> and, if that is the case, call `set-window-dedicated-p' for that
> window with some non-nil, non-t flag.  If someone can come up
> with a simpler solution I'll be all ears.

Sigh.



----

** Such a tendency is already underway. Compare the `special-display-regexps'
doc strings for
Emacs 20 and 23, below.  Will the Emacs 26 doc string read only like a legal
disclaimer? Don't get me wrong.  The reference doc should be complete and
correct.  But doc should also help you to see the forest, not just become lost
in the forest litter.

20:

List of regexps saying which buffers should have their own special frames.
If a buffer name matches one of these regexps, it gets its own frame.
Displaying a buffer whose name is in this list makes a special frame for it
using `special-display-function'.

An element of the list can be a list instead of just a string.
There are two ways to use a list as an element:
  (REGEXP FRAME-PARAMETERS...)   (REGEXP FUNCTION OTHER-ARGS...)
In the first case, FRAME-PARAMETERS are used to create the frame.
In the latter case, FUNCTION is called with the buffer as first argument,
followed by OTHER-ARGS--it can display the buffer in any way it likes.
All this is done by the function found in `special-display-function'.

If this variable appears "not to work", because you add a regexp to it
but the matching buffers still appear in the selected window, look at the
values of `same-window-buffer-names' and `same-window-regexps'.
Those variables take precedence over this one.

23:

List of regexps saying which buffers should be displayed specially.
Displaying a buffer with `display-buffer' or `pop-to-buffer', if
any regexp in this list matches its name, displays it specially
using `special-display-function'.  `special-display-popup-frame'
(the default for `special-display-function') usually displays
the buffer in a separate frame made with the parameters specified
by `special-display-frame-alist'.  If `special-display-function'
has been set to some other function, that function is called with
the buffer as first, and nil as second argument.

Alternatively, an element of this list can be specified as
(REGEXP FRAME-PARAMETERS), where REGEXP is a regexp as above and
FRAME-PARAMETERS an alist of (PARAMETER . VALUE) pairs.
`special-display-popup-frame' will then interpret these pairs as
frame parameters when creating a special frame for a buffer whose
name matches REGEXP, overriding the corresponding values from
`special-display-frame-alist'.

As a special case, if FRAME-PARAMETERS contains (same-window . t)
`special-display-popup-frame' displays buffers matching REGEXP in
the selected window.  (same-frame . t) in FRAME-PARAMETERS means
to display such buffers in a window on the selected frame.

If `special-display-function' specifies some other function than
`special-display-popup-frame', that function is called with the
buffer whose name matched REGEXP as first, and FRAME-PARAMETERS
as second argument.

Finally, an element of this list can be also specified as
(REGEXP FUNCTION OTHER-ARGS).  `special-display-popup-frame'
will then call FUNCTION with the buffer whose name matched
REGEXP as first, and OTHER-ARGS as second argument.  If
`special-display-function' specifies some other function, that
function is called with the buffer whose name matched REGEXP
as first, and the element's cdr as second argument.

If this variable appears "not to work", because you added a
name to it but the corresponding buffer is displayed in the
selected window, look at the values of `same-window-buffer-names'
and `same-window-regexps'.  Those variables take precedence over
this one.

See also `special-display-buffer-names'.

bug#6280: 24.0.50; (elisp) Dedicated Windows

[martin rudalics]

 > My value of `special-display-regexps' is ("[ ]?[*][^*]+[*]"), so buffers named
 > `*...*' are special.

In your original report you asked for

 > * a simple recipe for making all windows dedicated and
 >
 > * a simple recipe for making all windows for buffers in a certain mode
 > dedicated

I tried to answer these questions.

 >> I earlier mentioned how you can do what the OP wants.  Write
 >> a function that you _globally_ add to
 >> `window-configuration-change-hook'.  That function would have to
 >> scan `window-list', check for each window whether
 >> its buffer is in a mode that shall have dedicated windows,
 >> and, if that is the case, call `set-window-dedicated-p' for that
 >> window with some non-nil, non-t flag.  If someone can come up
 >> with a simpler solution I'll be all ears.
 >
 > Sigh.

Sorry.

martin

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> 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.
>
> Dedicated windows have an entire section in the Elisp manual.  What is
> not sufficiently clear there?

Looks clear enough to me.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

> > Dedicated windows have an entire section in the Elisp manual.
> > What is not sufficiently clear there?
> 
> Looks clear enough to me.  Closing.

Did you read the bug report?  It was NOT saying that node
`Dedicated Windows' in (elisp) is unclear.  It said nothing of
the kind.

So that reason for closing this bug (which is not about that)
is 100% a red herring.

To repeat what I said before:

> I was clear about what is needed for the doc about this topic:
> 
> 1. Put something in the Emacs manual about how to make windows
>    dedicated.
>
> 2. In the Elisp manual, mention `special-display' buffers in node
>    `Dedicated Windows'.
> 
> See the original bug report for details.

There is NOTHING in the Emacs manual about dedicated windows,
except for this mention in passing (in node `Minibuffer Edit'),
which offers no explanation and has not even a cross reference
to the Elisp manual for the topic:

  When not active, the minibuffer is in `minibuffer-inactive-mode',
  and clicking `Mouse-1' there shows the `*Messages*' buffer.  If
  you use a dedicated frame for minibuffers, Emacs also recognizes
  certain keys there, for example `n' to make a new frame.

The bug is still a bug.  There is nothing in the Emacs manual
about how to make windows dedicated.  And there is no mention of
`special-display' buffers in (elisp) `Dedicated Windows'.

bug#6280: 24.0.50; (elisp) Dedicated Windows

[martin rudalics]

 > There is NOTHING in the Emacs manual about dedicated windows,
 > except for this mention in passing (in node `Minibuffer Edit'),
 > which offers no explanation and has not even a cross reference
 > to the Elisp manual for the topic:
 >
 >   When not active, the minibuffer is in `minibuffer-inactive-mode',
 >   and clicking `Mouse-1' there shows the `*Messages*' buffer.  If
 >   you use a dedicated frame for minibuffers, Emacs also recognizes
 >   certain keys there, for example `n' to make a new frame.

I'm not sure what a dedicated frame is but IIUC it's not just a frame
containing a dedicated window.  Maybe it's a minibuffer-only frame?

 >  And there is no mention of
 > `special-display' buffers in (elisp) `Dedicated Windows'.

Maybe so because `special-display' buffers are not specified anywhere in
the Elisp manual.

martin

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Stefan Monnier]

>> When not active, the minibuffer is in `minibuffer-inactive-mode',
>> and clicking `Mouse-1' there shows the `*Messages*' buffer.  If
>> you use a dedicated frame for minibuffers, Emacs also recognizes
>> certain keys there, for example `n' to make a new frame.
> I'm not sure what a dedicated frame

In the above text, "dedicated frame" is not a special concept, it's just
talking a way to say it's a frame which the user has created for
a particular purpose.

> Maybe it's a minibuffer-only frame?

Yes.


        Stefan

bug#6280: 24.0.50; (elisp) Dedicated Windows

[Drew Adams]

> In the above text, "dedicated frame" is not a special concept, it's
> just talking a way to say it's a frame which the user has created
> for a particular purpose.

In that case, it should use different phrasing, to avoid confusion
with dedicated windows.  Say, e.g., "a frame which the user has
created for a particular purpose".

Of course, with such clearer phrasing it becomes clear that this
doesn't mean anything at all.  Not unless you say what you have
in mind by "for a particular purpose".  What frame creation is
not for a particular purpose?

If this is to be helpful/meaningful, it needs to actually say
something.  Perhaps an example of what you have in mind would
help - an example of a frame "created for a particular purpose".

If all you mean is a standalone minibuffer frame, then say that.
Don't use the word "dedicated" at all.  If you think that is
not clear enough, then say a frame whose `minibuffer' parameter
has value `only'.