make-frame-command with multiple munitors

make-frame-command with multiple munitors

[Pascal Quesseveur]

Hello,

When I work with several monitors I would like that when, in a frame,
I run a command which opens a new frame, this frame is created on the
same monitor as that of the current frame, which is not always the
case.

Function make-frame-on-current-monitor exists to meet this use case
but it is not really easy to use interactively. Variable
pop-up-frame-function can be set to use a function different from
make-frame for creating a new frame in display-buffer-pop-up-frame.

I have used pop-up-frame-function to use make-frame-on-current-monitor
instead of make-frame. That works fine but there is no easy way to do
the same with special-display-popup-frame or make-frame-command.

IMHO it would be worth to use such a variable in those functions too.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: make-frame-command with multiple munitors

[Juri Linkov]

> When I work with several monitors I would like that when, in a frame,
> I run a command which opens a new frame, this frame is created on the
> same monitor as that of the current frame, which is not always the
> case.
>
> Function make-frame-on-current-monitor exists to meet this use case
> but it is not really easy to use interactively. Variable
> pop-up-frame-function can be set to use a function different from
> make-frame for creating a new frame in display-buffer-pop-up-frame.
>
> I have used pop-up-frame-function to use make-frame-on-current-monitor
> instead of make-frame. That works fine but there is no easy way to do
> the same with special-display-popup-frame or make-frame-command.
>
> IMHO it would be worth to use such a variable in those functions too.

Sorry, the last line is unclear, please explain
what variable and in what functions?

Re: make-frame-command with multiple munitors

[wilnerthomas--- via Emacs development discussions.]

Sep 17, 2022, 17:55 by juri@linkov.net:

>> When I work with several monitors I would like that when, in a frame,
>> I run a command which opens a new frame, this frame is created on the
>> same monitor as that of the current frame, which is not always the
>> case.
>>
>> Function make-frame-on-current-monitor exists to meet this use case
>> but it is not really easy to use interactively. Variable
>> pop-up-frame-function can be set to use a function different from
>> make-frame for creating a new frame in display-buffer-pop-up-frame.
>>
>> I have used pop-up-frame-function to use make-frame-on-current-monitor
>> instead of make-frame. That works fine but there is no easy way to do
>> the same with special-display-popup-frame or make-frame-command.
>>
>> IMHO it would be worth to use such a variable in those functions too.
>>
>
> Sorry, the last line is unclear, please explain
> what variable and in what functions?
>
I wonder how can one pass a frame to a function that needs it as argument.

My frame reports as

 #<frame *scratch* - GNU Emacs at zeus 0x2c88d40>

And I want to call

(set-frame-position frame nlft ntop)

Re: make-frame-command with multiple munitors

[Pascal Quesseveur]

>"JL" == Juri Linkov <juri@linkov.net> writes:

  JL> Sorry, the last line is unclear, please explain
  JL> what variable and in what functions?

I imagine there's a reason make-frame-on-current-monitor didn't
outright replace make-frame (personally it seems more normal to me to
always open a new frame on the current monitor, but I can imagine
that this is not the general case.)

A variable similar to pop-up-frame-function could be used in functions
make-frame-command and special-display-popup-frame, which would allow
a user to override the use of make-frame in those functions too.

Or maybe these functions could also use pop-up-frame-function, but
that doesn't seem to be what was intended.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: make-frame-command with multiple munitors

[Po Lu]

Pascal Quesseveur <pquessev@gmail.com> writes:

> I imagine there's a reason make-frame-on-current-monitor didn't
> outright replace make-frame (personally it seems more normal to me to
> always open a new frame on the current monitor, but I can imagine
> that this is not the general case.)

Because opening a frame on the right monitor is the job of the window
manager, not Emacs.

Notice how make-frame-on-current-monitor always sets the "user specified
position" flag in the window manager hints property.  The window manager
will then blindly obey the initial position (0, 0 from the origin of the
monitor) instead of placing the window in the right monitor while also
taking into account window placement constraints and policy.

Re: make-frame-command with multiple munitors

[Christopher Dimech]

> Sent: Tuesday, September 20, 2022 at 12:28 AM
> From: "Po Lu" <luangruo@yahoo.com>
> To: "Pascal Quesseveur" <pquessev@gmail.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> Subject: Re: make-frame-command with multiple munitors
>
> Pascal Quesseveur <pquessev@gmail.com> writes:
>
> > I imagine there's a reason make-frame-on-current-monitor didn't
> > outright replace make-frame (personally it seems more normal to me to
> > always open a new frame on the current monitor, but I can imagine
> > that this is not the general case.)
>
> Because opening a frame on the right monitor is the job of the window
> manager, not Emacs.

Emacs has the capability of placing a frame at some position.  It is then
logical for emacs to look into the monitor configuration to determine the
current monitor (then placing at corners or center oy monitor).  It would
a feature very much appreciated if made to happen.

> Notice how make-frame-on-current-monitor always sets the "user specified
> position" flag in the window manager hints property.  The window manager
> will then blindly obey the initial position (0, 0 from the origin of the
> monitor) instead of placing the window in the right monitor while also
> taking into account window placement constraints and policy.

>

Re: make-frame-command with multiple munitors

[Po Lu]

Christopher Dimech <dimech@gmx.com> writes:

> Emacs has the capability of placing a frame at some position.  It is then
> logical for emacs to look into the monitor configuration to determine the
> current monitor (then placing at corners or center oy monitor).  It would
> a feature very much appreciated if made to happen.

That already exists, which is make-frame-on-current-monitor.  But a
modern window manager almost always does it better out of the box, which
is why make-frame is the default.

Re: make-frame-command with multiple munitors

[Christopher Dimech]

> Sent: Tuesday, September 20, 2022 at 1:38 AM
> From: "Po Lu" <luangruo@yahoo.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Pascal Quesseveur" <pquessev@gmail.com>, emacs-devel@gnu.org, juri@linkov.net
> Subject: Re: make-frame-command with multiple munitors
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Emacs has the capability of placing a frame at some position.  It is then
> > logical for emacs to look into the monitor configuration to determine the
> > current monitor (then placing at corners or center oy monitor).  It would
> > a feature very much appreciated if made to happen.
>
> That already exists, which is make-frame-on-current-monitor.  But a
> modern window manager almost always does it better out of the box, which
> is why make-frame is the default.

Something equally useful is to make the initial frame on current monitor.

Re: make-frame-command with multiple munitors

[Pascal Quesseveur]

>"PL" == Po Lu <luangruo@yahoo.com> writes:

  PL> Because opening a frame on the right monitor is the job of the
  PL> window manager, not Emacs.

But when the WM doesn't do it, I don't find it good that emacs doesn't
do it either. Emacs is not only used with smart WMs. Most of the time
I work on Windows and I find annoying the placement of new frames. I'm
quite happy to be able to use make-frame-on-current-monitor and I
would have liked to be able to generalize this use.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: make-frame-command with multiple munitors

[Juri Linkov]

> I imagine there's a reason make-frame-on-current-monitor didn't
> outright replace make-frame (personally it seems more normal to me to
> always open a new frame on the current monitor, but I can imagine
> that this is not the general case.)
>
> A variable similar to pop-up-frame-function could be used in functions
> make-frame-command and special-display-popup-frame, which would allow
> a user to override the use of make-frame in those functions too.

The only variable that currently you can use is
special-display-frame-alist (that is like pop-up-frame-alist),
but geometry parameters should be specified manually.

> Or maybe these functions could also use , but
> that doesn't seem to be what was intended.

It seems the default behavior of make-frame-command can't be changed,
as well as the default value of pop-up-frame-function.

Re: make-frame-command with multiple munitors

[Christopher Dimech]

> Sent: Tuesday, September 20, 2022 at 5:58 AM
> From: "Pascal Quesseveur" <pquessev@gmail.com>
> To: emacs-devel@gnu.org
> Subject: Re: make-frame-command with multiple munitors
>
> >"PL" == Po Lu <luangruo@yahoo.com> writes:
>
>   PL> Because opening a frame on the right monitor is the job of the
>   PL> window manager, not Emacs.
>
> But when the WM doesn't do it, I don't find it good that emacs doesn't
> do it either. Emacs is not only used with smart WMs. Most of the time
> I work on Windows and I find annoying the placement of new frames. I'm
> quite happy to be able to use make-frame-on-current-monitor and I
> would have liked to be able to generalize this use.

I quite agree with Pascal.  Generalising to have "make-initial-frame-on-current-monitor"
would be valuable for situation when the system does not handle things very well.

Re: make-frame-command with multiple munitors

[Juri Linkov]

>> Or maybe these functions could also use , but
>> that doesn't seem to be what was intended.
>
> It seems the default behavior of make-frame-command can't be changed,
> as well as the default value of pop-up-frame-function.

I recall seeing a variable like 'make-frame-function',
but now can't find it.  Such a variable could help you
to replace its default value 'make-frame' with
customized value 'make-frame-on-current-monitor'.
This requires changing all current calls of
'make-frame' to (funcall 'make-frame-function).

Re: make-frame-command with multiple munitors

[Emanuel Berg]

Pedro Andres Aranda Gutierrez wrote:

>> Emacs has the capability of placing a frame at some
>> position. It is then logical for emacs to look into the
>> monitor configuration to determine the current monitor
>> (then placing at corners or center oy monitor). It would
>> a feature very much appreciated if made to happen.
>
> +1

`1+'

-- 
underground experts united
https://dataswamp.org/~incal

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Christopher Dimech <dimech@gmx.com> writes:
>
>> Emacs has the capability of placing a frame at some position.  It is then
>> logical for emacs to look into the monitor configuration to determine the
>> current monitor (then placing at corners or center oy monitor).  It would
>> a feature very much appreciated if made to happen.
>
> +1. I'm doing it on my own with:
> (defun reposition-after-init ()
>   "Re-position the frame in a display (Only for emacs 29 and above)"
>   (when (> emacs-major-version 28)
>     (let* ((monitor-attributes (frame-monitor-attributes))
>            (work-area (assq 'workarea monitor-attributes))
>            (x-min (nth 1 work-area))
>            (y-min (nth 2 work-area))
>            (new-x  (+ x-min 32))
>            (new-y  (+ y-min 32)))
>       (message "work-area: %s -> %d %d" work-area new-x new-y)
>       (set-frame-position (selected-frame) new-x new-y))))
> Hooked to the startup in
>
> (add-hook #'after-init-hook #'reposition-after-init)
>
> This works when you do NOT specify (left or top) in the default-frame-alist or initial-frame-alist 
>
> It would be nice to have a (current-monitor . t) in the default-frame-alist or initial-frame-alist to do this ;-)

What window manager are you using?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

That code works on GNOME and macOS

On Tue, 20 Sept 2022 at 13:07, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > Christopher Dimech <dimech@gmx.com> writes:
> >
> >> Emacs has the capability of placing a frame at some position.  It is
> then
> >> logical for emacs to look into the monitor configuration to determine
> the
> >> current monitor (then placing at corners or center oy monitor).  It
> would
> >> a feature very much appreciated if made to happen.
> >
> > +1. I'm doing it on my own with:
> > (defun reposition-after-init ()
> >   "Re-position the frame in a display (Only for emacs 29 and above)"
> >   (when (> emacs-major-version 28)
> >     (let* ((monitor-attributes (frame-monitor-attributes))
> >            (work-area (assq 'workarea monitor-attributes))
> >            (x-min (nth 1 work-area))
> >            (y-min (nth 2 work-area))
> >            (new-x  (+ x-min 32))
> >            (new-y  (+ y-min 32)))
> >       (message "work-area: %s -> %d %d" work-area new-x new-y)
> >       (set-frame-position (selected-frame) new-x new-y))))
> > Hooked to the startup in
> >
> > (add-hook #'after-init-hook #'reposition-after-init)
> >
> > This works when you do NOT specify (left or top) in the
> default-frame-alist or initial-frame-alist
> >
> > It would be nice to have a (current-monitor . t) in the
> default-frame-alist or initial-frame-alist to do this ;-)
>
> What window manager are you using?
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2596 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> That code works on GNOME and macOS

Don't the GNOME and Mac OS window managers do that automatically?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Nope...
/PA

On Wed, 21 Sept 2022 at 04:15, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > That code works on GNOME and macOS
>
> Don't the GNOME and Mac OS window managers do that automatically?
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1079 bytes --]

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

OK... a longer answer ;-)
the moment you include (top . xxx) or (left . xxx) in the
(default|init)-frame-alist the vales are taken as absolute values in the
window manager's space, and Emacs will be placed (normally) somewhere in
the display that is designated as 0 (the Linux laptop or MacBook Pro)
independently of which display you were when you lunched Emacs.

Rechecked on GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2022-09-17

/PA

On Wed, 21 Sept 2022 at 07:08, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> Nope...
> /PA
>
> On Wed, 21 Sept 2022 at 04:15, Po Lu <luangruo@yahoo.com> wrote:
>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>> > That code works on GNOME and macOS
>>
>> Don't the GNOME and Mac OS window managers do that automatically?
>>
>
>
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2467 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> OK... a longer answer ;-) the moment you include (top . xxx) or (left
> . xxx) in the (default|init)-frame-alist the vales are taken as
> absolute values in the window manager's space, and Emacs will be
> placed (normally) somewhere in the display that is designated as 0
> (the Linux laptop or MacBook Pro) independently of which display you
> were when you lunched Emacs.

Well yes, that's intentional behavior.  Setting `top' or `left' tells
the window manager to try very hard to place the frame at the specified
location on the screen.  If you want the frame to be placed at the
correct location, you will have to either remove both position
parameters from initial-frame-alist, for it to be positioned by the WM,
or manually specify the position of the monitor you want.

A note about terminology from the POV of Emacs: the normal coordinate
space of a connection to the X server (the connection is referred to as
a "display") is relative to the root window of the display's default
screen.  A screen is then split into different "monitors", which are
potentially overlapping rectangular subsets of the screen's root window,
normally displayed in a single physical monitor, not counting overscan
or underscan.

`top' and `left' coordinates are specified relative to the root window
of the screen, not "in the display that is designated to 0", nor is such
a coordinate system affected by the monitor in which the initial frame
was created.  Where in the root window coordinate system individual
monitors are placed can only be determined by the output of
display-monitor-attributes-list.

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

I stand corrected ... this is what happens when the morning coffee has not
yet kicked in and you write an email ;-)

So, in my case, i observe that the root window both on my Linux Laptop and
on the Macbook Pro coincides with the device's display.
I have the device on my right and I place an additional physical display on
the left. So the + 32 in my code is the equivalent I found
to the (left . 32) (top .32) in the xx-frame-alist.

And once again, it would be nice to have something to mimic the behaviour
of my code in Emacs. I don't know, maybe an
(on-active . t)  in the xx-frame-alist???

Just a suggestion...
 /PA

On Wed, 21 Sept 2022 at 07:45, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > OK... a longer answer ;-) the moment you include (top . xxx) or (left
> > . xxx) in the (default|init)-frame-alist the vales are taken as
> > absolute values in the window manager's space, and Emacs will be
> > placed (normally) somewhere in the display that is designated as 0
> > (the Linux laptop or MacBook Pro) independently of which display you
> > were when you lunched Emacs.
>
> Well yes, that's intentional behavior.  Setting `top' or `left' tells
> the window manager to try very hard to place the frame at the specified
> location on the screen.  If you want the frame to be placed at the
> correct location, you will have to either remove both position
> parameters from initial-frame-alist, for it to be positioned by the WM,
> or manually specify the position of the monitor you want.
>
> A note about terminology from the POV of Emacs: the normal coordinate
> space of a connection to the X server (the connection is referred to as
> a "display") is relative to the root window of the display's default
> screen.  A screen is then split into different "monitors", which are
> potentially overlapping rectangular subsets of the screen's root window,
> normally displayed in a single physical monitor, not counting overscan
> or underscan.
>
> `top' and `left' coordinates are specified relative to the root window
> of the screen, not "in the display that is designated to 0", nor is such
> a coordinate system affected by the monitor in which the initial frame
> was created.  Where in the root window coordinate system individual
> monitors are placed can only be determined by the output of
> display-monitor-attributes-list.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 3502 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> I stand corrected ... this is what happens when the morning coffee has not yet kicked in and you write an email ;-)
>
> So, in my case, i observe that the root window both on my Linux Laptop and on the Macbook Pro coincides with the device's display.
> I have the device on my right and I place an additional physical display on the left. So the + 32 in my code is the equivalent I found
> to the (left . 32) (top .32) in the xx-frame-alist. 

"Device's display?"

Which of "display", "screen" or "monitor" do you mean by that?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

Well... if I'm on the Linux laptop it's the laptop's TFT and if I'm on the
macbook Pro, I mean the Macbook Pro's TFT ...

/PA

On Wed, 21 Sept 2022 at 12:53, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > I stand corrected ... this is what happens when the morning coffee has
> not yet kicked in and you write an email ;-)
> >
> > So, in my case, i observe that the root window both on my Linux Laptop
> and on the Macbook Pro coincides with the device's display.
> > I have the device on my right and I place an additional physical display
> on the left. So the + 32 in my code is the equivalent I found
> > to the (left . 32) (top .32) in the xx-frame-alist.
>
> "Device's display?"
>
> Which of "display", "screen" or "monitor" do you mean by that?
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1739 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Well... if I'm on the Linux laptop it's the laptop's TFT and if I'm on
> the macbook Pro, I mean the Macbook Pro's TFT ...

Then as I said, the TRT is to get the offsets from
display-monitor-attributes-alist and to use those.