Splitting window displayed in special frame

Splitting window displayed in special frame

[Joe]

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?

Re: Splitting window displayed in special frame

[rgb]

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.

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

Re: Splitting window displayed in special frame

[rgb]

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

Well I somehow I was.
The way I read it, the value you want should be the one
getting returned...  So perhaps a bug report is in order.
Whereever it is, it's not obvious to me.

  tem = Fassq (param, alist);

  if (!NILP (tem))
    {
      /* If we find this parm in ALIST, clear it out
	 so that it won't be "left over" at the end.  */
#ifndef WINDOWSNT /* w32fns.c has not yet been changed to cope with 
this.  */
      Lisp_Object tail;
      XSETCAR (tem, Qnil);
      /* In case the parameter appears more than once in the alist,
	 clear it out.  */
      for (tail = alist; CONSP (tail); tail = XCDR (tail))
	if (CONSP (XCAR (tail))
	    && EQ (XCAR (XCAR (tail)), param))
	  XSETCAR (XCAR (tail), Qnil);
#endif
    }
  else
    tem = Fassq (param, Vdefault_frame_alist);
// irrelevant   if (EQ (tem, Qnil)) snipped.
  return Fcdr (tem);