frame.el: call before-make-frame-hook earlier in make-frame

frame.el: call before-make-frame-hook earlier in make-frame

[Florian]

Dear Emacs developers,

I would like to propose to call the before-make-frame-hook in the function
make-frame *before* retrieving the parameters of the new frame
(window-system-default-frame-alist and default-frame-alist) and not after.

That way, one could dynamically set these variables inside the hook, e.g. to
create the new frame under the current position of the mouse cursor.

frame.el:
[...]
(defun make-frame (&optional parameters)
[...]
    ;; NEW position of hook
    (run-hooks 'before-make-frame-hook)
    ;; Add parameters from `window-system-default-frame-alist'.
    (dolist (p (cdr (assq w window-system-default-frame-alist)))
      (unless (assq (car p) params)
        (push p params)))
    ;; Add parameters from `default-frame-alist'.
    (dolist (p default-frame-alist)
      (unless (assq (car p) params)
        (push p params)))
    ;; Now make the frame.
    ;; OLD position of hook
    ;;(run-hooks 'before-make-frame-hook)
[...]

Is there a reason that the hook is called after reading the params?

Kind regards,
Florian

Re: frame.el: call before-make-frame-hook earlier in make-frame

[Stephen Leake]

Florian <floriansbriefe@gmail.com> writes:

> Dear Emacs developers,
>
> I would like to propose to call the before-make-frame-hook in the function
> make-frame *before* retrieving the parameters of the new frame
> (window-system-default-frame-alist and default-frame-alist) and not after.
>
> That way, one could dynamically set these variables inside the hook, e.g. to
> create the new frame under the current position of the mouse cursor.
>
> frame.el:
> [...]
> (defun make-frame (&optional parameters)
> [...]
>     ;; NEW position of hook
>     (run-hooks 'before-make-frame-hook)
>     ;; Add parameters from `window-system-default-frame-alist'.
>     (dolist (p (cdr (assq w window-system-default-frame-alist)))
>       (unless (assq (car p) params)
>         (push p params)))
>     ;; Add parameters from `default-frame-alist'.
>     (dolist (p default-frame-alist)
>       (unless (assq (car p) params)
>         (push p params)))
>     ;; Now make the frame.
>     ;; OLD position of hook
>     ;;(run-hooks 'before-make-frame-hook)
> [...]
>
> Is there a reason that the hook is called after reading the params?

I would have guessed that 'before-make-frame-hook' could modify the
params set by the global variables. But it can't, since it doesn't have
access to the local variable 'params'.

So perhaps a better change would be to pass 'params' to
before-make-frame-hook so it can modify 'params'.

For compatibility, that probably requires a new hook.

--
-- Stephe

Re: frame.el: call before-make-frame-hook earlier in make-frame

[martin rudalics]

 > I would like to propose to call the before-make-frame-hook in the function
 > make-frame *before* retrieving the parameters of the new frame
 > (window-system-default-frame-alist and default-frame-alist) and not after.
 >
 > That way, one could dynamically set these variables inside the hook, e.g. to
 > create the new frame under the current position of the mouse cursor.

We could easily do that.  But encouraging users to set a variable called
`default-frame-alist' in a hook is probably a very bad advice.  Where
would you change the default value back after you're done with making
the frame?  In `after-make-frame-functions'?

Creating a frame under the mouse cursor should be done by a special
function that calls `make-frame' with the mouse position passed via the
`left' and `top' PARAMETERS thus _overriding_ any default parameters.
Please tell us if and why such a function would not be practicable for
you.

Thanks, martin

Re: frame.el: call before-make-frame-hook earlier in make-frame

[floriansbriefe]

> > I would like to propose to call the before-make-frame-hook in the function
> > make-frame *before* retrieving the parameters of the new frame
> > (window-system-default-frame-alist and default-frame-alist) and not after.
> >
> > That way, one could dynamically set these variables inside the hook, e.g. to
> > create the new frame under the current position of the mouse cursor.
> 
> We could easily do that.  But encouraging users to set a variable called
> `default-frame-alist' in a hook is probably a very bad advice.  Where
> would you change the default value back after you're done with making
> the frame?  In `after-make-frame-functions'?

As the hook is registered, the hook will always adjust the 'default-frame-alist'
and thereby make its value dynamic. There is no need to restore the former default.
But I see your point, that it is a kind of hack.

> Creating a frame under the mouse cursor should be done by a special
> function that calls `make-frame' with the mouse position passed via the
> `left' and `top' PARAMETERS thus _overriding_ any default parameters.
> Please tell us if and why such a function would not be practicable for
> you.

That is a viable solution, but it has the drawback that you have to override a
default key-binding (C-x 5 2) with your own make-frame function and that you do
not benefit from the nice things that 'make-frame-command' additionally does for
you a) at the moment (setting the focus to the new frame etc) and b) potentially
in future emacs releases. Thats why I would prefer using the hook. Thats what
hooks are for: Adjusting behaviour with minimal invasion.

Cheers,

Florian

Re: frame.el: call before-make-frame-hook earlier in make-frame

[martin rudalics]

 > That is a viable solution, but it has the drawback that you have to override a
 > default key-binding (C-x 5 2) with your own make-frame function and that you do
 > not benefit from the nice things that 'make-frame-command' additionally does for
 > you a) at the moment (setting the focus to the new frame etc)

Here `make-frame-command' does only

   (interactive)
   (if (display-graphic-p)
       (make-frame)
     (select-frame (make-frame))))

and since you are not on a text terminal (on a text terminal you can
hardly make a frame at the mouse position) `make-frame-command' is just
an interactive wrapper for `make-frame'.  Everything else (like
redirecting focus to the new frame) is done inside `make-frame'.

 > and b) potentially
 > in future emacs releases. Thats why I would prefer using the hook. Thats what
 > hooks are for: Adjusting behaviour with minimal invasion.

That hook would be run for any frames created by other packages, say for
the speedbar or the ediff control window.  Are you sure you want these
to pop up at the mouse position?  And how do you get the mouse position
when it's outside of any emacs frame?  Or do you want to position a new
frame always inside an existing frame?

martin

Re: frame.el: call before-make-frame-hook earlier in make-frame

[floriansbriefe]

> > That is a viable solution, but it has the drawback that you have to override a
> > default key-binding (C-x 5 2) with your own make-frame function and that you do
> > not benefit from the nice things that 'make-frame-command' additionally does for
> > you a) at the moment (setting the focus to the new frame etc)
> 
> Here `make-frame-command' does only
> 
>   (interactive)
>   (if (display-graphic-p)
>       (make-frame)
>     (select-frame (make-frame))))
> 
> and since you are not on a text terminal (on a text terminal you can
> hardly make a frame at the mouse position) `make-frame-command' is just
> an interactive wrapper for `make-frame'.  Everything else (like
> redirecting focus to the new frame) is done inside `make-frame'.

The use case was just an example, other dynamic settings would be possible.

> > in future emacs releases. Thats why I would prefer using the hook. Thats what
> > hooks are for: Adjusting behaviour with minimal invasion.
> 
> That hook would be run for any frames created by other packages, say for
> the speedbar or the ediff control window.  Are you sure you want these
> to pop up at the mouse position?  And how do you get the mouse position
> when it's outside of any emacs frame?  Or do you want to position a new
> frame always inside an existing frame?

If the mouse position cannot be determined I used a default position value.

But you are completely right for frames opened by other packages (speedbar,
ediff control window). I missed those cases in my considerations.

So your proposal of a separate 'make-frame' command for interactively created
frames seems to be the right choice and I will follow this approach.

Thank you very much for your advice!

Florian

Re: frame.el: call before-make-frame-hook earlier in make-frame

[martin rudalics]

 > If the mouse position cannot be determined I used a default position value.

One idea that comes to my mind is: Bind some key like C-M-mouse-1 to a
new command that

(1) Takes the window under the mouse,

(2) starts mouse-tracking and

(3) upon relasing the mouse button pops up a new frame at the last mouse
     position showing the window from (1).

martin

Re: frame.el: call before-make-frame-hook earlier in make-frame

[Florian]

> > > That is a viable solution, but it has the drawback that you have to override a
> > > default key-binding (C-x 5 2) with your own make-frame function and that you do
> > > not benefit from the nice things that 'make-frame-command' additionally does for
> > > you a) at the moment (setting the focus to the new frame etc)
> > 
> > Here `make-frame-command' does only
> > 
> >   (interactive)
> >   (if (display-graphic-p)
> >       (make-frame)
> >     (select-frame (make-frame))))

So, according to your advice I wrote my own 'make-frame-command' function that
is now bound to the normal 'C-x 5 2' key-sequence and calls make-frame with
dynamic parameters to place the window under the mouse cursor. That works quite
ok. But this is not the only way I create additional frames. The other way I
open new frames is by using emacsclient. How could I let emacsclient create the
new frame using my own version of make-frame-command?

Thanks,
Florian

Re: frame.el: call before-make-frame-hook earlier in make-frame

[martin rudalics]

 > So, according to your advice I wrote my own 'make-frame-command' function that
 > is now bound to the normal 'C-x 5 2' key-sequence and calls make-frame with
 > dynamic parameters to place the window under the mouse cursor. That works quite
 > ok. But this is not the only way I create additional frames. The other way I
 > open new frames is by using emacsclient. How could I let emacsclient create the
 > new frame using my own version of make-frame-command?

My knowledge of emacsclient is very limited.  And the fairly recent
introduction of `gui-method' has limited my knowledge of how frames are
created even more.  Hopefully someone else can give you an advice on how
to do what you want.

In any case, you should be able to use `after-make-frame-functions' in
order to reposition your frame on screen but I'm not sure whether that
could introduce some flickering.  Please try it.

martin

Re: frame.el: call before-make-frame-hook earlier in make-frame

[Eli Zaretskii]

> Date: Mon, 03 Aug 2015 12:41:42 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > So, according to your advice I wrote my own 'make-frame-command' function that
>  > is now bound to the normal 'C-x 5 2' key-sequence and calls make-frame with
>  > dynamic parameters to place the window under the mouse cursor. That works quite
>  > ok. But this is not the only way I create additional frames. The other way I
>  > open new frames is by using emacsclient. How could I let emacsclient create the
>  > new frame using my own version of make-frame-command?
> 
> My knowledge of emacsclient is very limited.  And the fairly recent
> introduction of `gui-method' has limited my knowledge of how frames are
> created even more.  Hopefully someone else can give you an advice on how
> to do what you want.

emacsclient supports --eval, perhaps that could serve as a starting
point.

Re: frame.el: call before-make-frame-hook earlier in make-frame

[Stefan Monnier]

> My knowledge of emacsclient is very limited.  And the fairly recent
> introduction of `gui-method' has limited my knowledge of how frames are
> created even more.

FWIW "gui-method"s have since disappeared,


        Stefan