Re: Splitting window displayed in special frame

[Joe]

On 26 Jan., 21:59, "rgb" <rbiel...@i1.net> wrote:
> On Jan 26, 6:41 am, "Joe" <Johannes.Labi...@gmail.com> wrote:
>
>
>
> > Hello,
>
> > I have set the variable special-display-buffer-names to
> >   (("*SQL*" (width . 139) ))))
> > .
> > Whenever I create a "*SQL*" buffer, it is displayed in a new frame as
> > it should be.
> > The only problem is that if something is happening in the mini-buffer
> > that creates a (temporary) window, like completion, the buffer
> > *Completions* is displayed in a different frame.
> > For instance, if I do find-file and press tab to get the file
> > completions list, it is displayed in another (existing) frame instead
> > of splitting the window temporary as it is done for other windows.
>
> > I tried to set special-display-buffer-names to
> >   (("*SQL*" (width . 139) (unsplittable . nil))))
> > but it had no effect.
>
> > It should not act different for *Completions* in the special-displayed
> > buffer from *Completions* of a function issued in a normal buffer.
> > How can I do that?
> I'ts hard to say if this is a bug or there is a good reason but
> special-display-popup-frame creates the frame like this:
>
> (make-frame (append args special-display-frame-alist))
>
> If unsplitable is non-nil in special-display-frame-alist it will
> appear after your nil version - which gets supplied from args.
>
> Making the frame happens in C code so I can't be sure
> exactly how and why but the conflict between the 2 sources
> of parameters is almost certainly the cause.
> If you're curious, look at x_get_arg, otherwise
> you might try reporting it as a bug and see what they say.

Interesting answer. Does that mean, there is currently no possibility 
for me to change the behaviour?
I understand this: setting  unsplittable  is ignored because of the 
way the special frame is created.
In that case it is definately a bug.

No, I am not THAT curious.  :-)