RE: Emacs geometry

RE: Emacs geometry

[Drew Adams]

CCing the list.

    -----Original Message-----
    From: Robert_Thorpe@Dell.com [mailto:Robert_Thorpe@Dell.com]
    Sent: Thursday, July 27, 2006 8:38 AM
    To: drew.adams@oracle.com
    Subject: RE: Emacs geometry

    ...
    > cc'ing the list. I assume that the problem is that it is not
    > known how to let Emacs know where the task bar is. What you
    > suggest is obviously the best solution, if can be done.

    Use the SPI_GETWORKAREA switch to SystemParametersInfo

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
    /html/cerefSystemParametersInfo.asp

    I'm surpised Emacs doesn't already do this, it seems the most obvious
    thing to call.

    CC this to the list too if it is useful.

    Rob

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 27 Jul 2006 08:49:10 -0700
> Cc: 
> 
>     Use the SPI_GETWORKAREA switch to SystemParametersInfo
> 
>     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
>     /html/cerefSystemParametersInfo.asp

You will see that I initially suggested precisely that in this
message:

  http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/msg00287.html

but I think the solution found by Ralf is better, as it makes Emacs
behave on Windows like it does on other windowing systems: let the
window manager position the window, unless told otherwise.

RE: Emacs geometry

[Robert_Thorpe]

> -----Original Message-----
> From: Eli Zaretskii 
> Sent: 28 July 2006 10:53
> Subject: Re: Emacs geometry
> 
> > From: "Drew Adams"
> > Date: Thu, 27 Jul 2006 08:49:10 -0700
> > Cc: 
> > 
> >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
> > 
> >     
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/wceui40
> >     /html/cerefSystemParametersInfo.asp
> 
> You will see that I initially suggested precisely that in this
> message:
> 
>   
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/ms
> g00287.html
> 
> but I think the solution found by Ralf is better, as it makes 
> Emacs behave on Windows like it does on other windowing 
> systems: let the window manager position the window, unless 
> told otherwise.

That would work fine for me since I use initial-frame-alist to
position the Emacs frame.  It will probably be OK for most
MS Windows users too.

It's worth noting though that there is no concept of window
management in MS Windows.  Windows are not placed on the screen
in a systematic way, they are just put in the same place.

As an experiment start up several programs in Windows and see
where their windows appear relative to each other.  Then start
up the same programs in a different order.  On my machine at
least the result is the same positions in both cases.  The only
exception to this behaviour is command prompt windows, which
take into account the position of the last cmd prompt window
when placing the next one.  I think the behaviour has always
been like this.

Rob

Re: Emacs geometry

[Eli Zaretskii]

> Date: Fri, 28 Jul 2006 11:07:31 +0100
> From: <Robert_Thorpe@Dell.com>
> Cc: <emacs-devel@gnu.org>
> 
> It's worth noting though that there is no concept of window
> management in MS Windows.  Windows are not placed on the screen
> in a systematic way, they are just put in the same place.

Where windows are placed depends on the application.  Some
applications record their last position and place themselves there,
others don't.

Re: Emacs geometry

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]

Eli Zaretskii wrote:
>> From: "Drew Adams" <drew.adams@oracle.com>
>> Date: Thu, 27 Jul 2006 08:49:10 -0700
>> Cc: 
>>
>>     Use the SPI_GETWORKAREA switch to SystemParametersInfo
>>
>>     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
>>     /html/cerefSystemParametersInfo.asp
>>     
>
> You will see that I initially suggested precisely that in this
> message:
>
>   http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/msg00287.html
>
> but I think the solution found by Ralf is better, as it makes Emacs
> behave on Windows like it does on other windowing systems: let the
> window manager position the window, unless told otherwise.
>   
Using SPI_GETWORKAREA also confines the frames to the primary desktop on 
multi-monitor systems.


[-- Attachment #1.2: Type: text/html, Size: 1438 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: Emacs geometry

[Drew Adams]

    > From: "Drew Adams" <drew.adams@oracle.com>
    > Date: Thu, 27 Jul 2006 08:49:10 -0700
    > Cc:
    >
    >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
    >
    >
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
    >     /html/cerefSystemParametersInfo.asp

One minor objection - This attributes the post to me; it was not mine. I've
posted nothing to the discussion about how to fix this in C. My only posts
in this thread were to point out the problems created by the design change.

RE: Emacs geometry

[Nick Roberts]

Drew Adams writes:
 >     > From: "Drew Adams" <drew.adams@oracle.com>
 >     > Date: Thu, 27 Jul 2006 08:49:10 -0700
 >     > Cc:
 >     >
 >     >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
 >     >
 >     >
 >     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
 >     >     /html/cerefSystemParametersInfo.asp
 > 
 > One minor objection - This attributes the post to me; it was not mine.

No it doesn't, it reflects the way you post to the list.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: Emacs geometry

[Drew Adams]

    Drew Adams writes:
     >     > From: "Drew Adams" <drew.adams@oracle.com>
     >     > Date: Thu, 27 Jul 2006 08:49:10 -0700
     >     > Cc:
     >     >
     >     >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
     >     >
     >     >
     >
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
     >     >     /html/cerefSystemParametersInfo.asp
     >
     > One minor objection - This attributes the post to me; it was
    not mine.

    No it doesn't, it reflects the way you post to the list.

Gee, how does it do that? Just how do I post to the list?

Prior to "One minor objection...", absolutely nothing that was quoted was
sent by me - not one character, including, of course, "From: Drew Adams".
How does any of that content sent by others reflect how I post to the list?
It seems to me that it reflects the editing of the other posters.

RE: Emacs geometry

[Nick Roberts]

Drew Adams writes:
 >      > One minor objection - This attributes the post to me; it was
 >     not mine.
 > 
 >     No it doesn't, it reflects the way you post to the list.
 > 
 > Gee, how does it do that? Just how do I post to the list?

Sorry, I was wrong in this case, as I didn't check that particular message.
Generally though there's no way to see to whom you're replying.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 28 Jul 2006 06:45:34 -0700
> 
>     > From: "Drew Adams" <drew.adams@oracle.com>
>     > Date: Thu, 27 Jul 2006 08:49:10 -0700
>     > Cc:
>     >
>     >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
>     >
>     >
>     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40
>     >     /html/cerefSystemParametersInfo.asp
> 
> One minor objection - This attributes the post to me

It does nothing of the kind: it simply replies to your message.  The
TAB indentation clearly shows that you were quoting someone else.

RE: Emacs geometry

[Drew Adams]

          > From: "Drew Adams" <drew.adams@oracle.com>
          > Date: Thu, 27 Jul 2006 08:49:10 -0700
          > Cc:
          >
          >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
          >
          >     http://msdn.microsoft.com/library/default.asp?
          >     url=/library/en-us/wceui40
          >     /html/cerefSystemParametersInfo.asp

       One minor objection - This attributes the post to me

    It does nothing of the kind: it simply replies to your message.  The
    TAB indentation clearly shows that you were quoting someone else.

Uh, I was quoting no one. And I wasn't quoted, although it seems as though I
was. And it wasn't my message that was replied to, although it seems as
though it was.

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 29 Jul 2006 07:42:59 -0700
> 
>           > From: "Drew Adams" <drew.adams@oracle.com>
>           > Date: Thu, 27 Jul 2006 08:49:10 -0700
>           > Cc:
>           >
>           >     Use the SPI_GETWORKAREA switch to SystemParametersInfo
>           >
>           >     http://msdn.microsoft.com/library/default.asp?
>           >     url=/library/en-us/wceui40
>           >     /html/cerefSystemParametersInfo.asp
> 
>        One minor objection - This attributes the post to me
> 
>     It does nothing of the kind: it simply replies to your message.  The
>     TAB indentation clearly shows that you were quoting someone else.
> 
> Uh, I was quoting no one. And I wasn't quoted, although it seems as though I
> was. And it wasn't my message that was replied to, although it seems as
> though it was.

And it wasn't me who replied to it.

RE: Emacs geometry

[Drew Adams]

    -----Original Message-----
    From: Robert_Thorpe@Dell.com [mailto:Robert_Thorpe@Dell.com]
    Sent: Thursday, July 27, 2006 2:57 AM
    To: jasonr@gnu.org; mathias.dahl@gmail.com; drew.adams@oracle.com;
    eliz@gnu.org; sridhar_ml@yahoo.com
    Subject: Emacs geometry

    I've been reading the Emacs geometry discussion on emacs-devel.  Some
    possibly useful comments...

    To those puzzled about how you move the taskbar on Windows: It's easy,
    you drag it.  It can go at the top or either side.  I know no Windows
    users who put it at the top, but I know some who put it at the side.  I
    think you can do this on some X Window managers too.

    The solution seems to me to position Emacs relative to a different
    rectangle.  Rather than positioning it relative to the Desktop rectangle
    it should be positioned relative to the rectangle = (Desktop rect -
    Taskbar rect).  I think this will ensure it always pops up in a usable
    place, even if all the other behaviour were exactly the same as 21.3.

    Copy this to the list if you think it's useful.

    Rob

cc'ing the list. I assume that the problem is that it is not known how to
let Emacs know where the task bar is. What you suggest is obviously the best
solution, if can be done.

Re: Emacs geometry

[Jason Rumney]

Drew Adams wrote:
> cc'ing the list. I assume that the problem is that it is not known how to
> let Emacs know where the task bar is. What you suggest is obviously the best
> solution, if can be done.
>   

The best solution is to let the window manager place the window in the 
absence of any specific placement instructions from the user, as the 
window manager knows all about which areas on the desktop are hidden 
behind taskbars, sidebars and any other desktop furniture that may be 
invented in future. That is the way it has always worked on X, and is 
the way it works now on MS-Windows.

Emacs geometry

[Sridhar Boovaraghavan]

Hi,

I am using the latest CVS emacs on Windows XP. It is compiled using VS 2002.
This problem has recently started occurring. New frames in emacs are now offset
(by about a line both horizontally and vertically) from the existing frame.
Previously, all frames used to be offset +0+0 from the left-top corner of the
screen (i.e no offsetting was taking place). I don't believe I have any
code/setting that does this. My Emacs.geometry registry entry used to specify
80x48. I tried 80x48+0+0, but got  the same behavior as before.

Is there a new setting that I need to use or is this "by design" that others are
also encountering? If it is the latter, what is the setting that would cause all
frames not to exhibit offsetting?

Thanks,
Sridhar

RE: Emacs geometry

[Drew Adams]

    I am using the latest CVS emacs on Windows XP. It is compiled 
    using VS 2002.
    This problem has recently started occurring. New frames in 
    emacs are now offset
    (by about a line both horizontally and vertically) from the 
    existing frame.
    Previously, all frames used to be offset +0+0 from the left-top 
    corner of the
    screen (i.e no offsetting was taking place). I don't believe I have any
    code/setting that does this. My Emacs.geometry registry entry 
    used to specify
    80x48. I tried 80x48+0+0, but got  the same behavior as before.
    
    Is there a new setting that I need to use or is this "by 
    design" that others are
    also encountering? If it is the latter, what is the setting 
    that would cause all
    frames not to exhibit offsetting?
    
I reported this bug recently to Fran Litterio. 
I think he might be working on fixing it. - Drew

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 24 Jul 2006 14:25:28 -0700
> 
> I reported this bug recently to Fran Litterio. 

What bug, and in which message did you report it?

RE: Emacs geometry

[Drew Adams]

    > From: "Drew Adams" <drew.adams@oracle.com>
    > I reported this bug recently to Fran Litterio.

    What bug, and in which message did you report it?

As I said, I reported it to Fran, as at first I thought it was related to
his fix of another frame positioning bug I reported. Here is most of what I
sent to Fran, followed by my view of this new behavior and a request to put
things back the way they were.

----

With emacs -Q:

The initial frame is 2 or 3 cm from the upper left of the display (more or
less like what happens if you do (set-frame-position (selected-frame) 100
100)); in the past, the initial frame has always been flush with top left.

Playing with `make-frame' a little, I'm convinced that that is the problem,
but I don't quite understand what's going on. It seems to open frames in
different places, not necessarily with regard to standard "cascading" (to
the right and down) from the current frame.

I'm not sure that the position of a frame created by `make-frame' is
specified by Emacs, if you don't supply a frame alist, but the behavior
seems wrong now generally, and it is quite different from the behavior
before. It also seems inconsistent now, and it was consistent before.

In my own code (not emacs -Q, which was the case for the above description),
here are 1) the alist I pass to `make-frame' to create a standalone
minibuffer frame and 2) my value of `default-frame-alist'.

Minbuffer:

(...
 (menu-bar-lines)
 (height . 2)
 (icon-type . t)
 (minibuffer . only)
 (user-position . t)
 (vertical-scroll-bars))

`default-frame-alist':

(...
 (menu-bar-lines . 1)
 (top . 0)
 (left . 0)
 (width . 80)
 (height . 35)
 (minibuffer)
 (user-position . t)
 (tool-bar-lines . 1)
 (left-fringe . 0)
 (right-fringe . 0)
 (fringe . 0)
 (menu-bar-lines . 1))

I don't impose a top, left position for the minibuffer frame using the
alist; I position that frame afterward, using `modify-frame-parameters'.

I do impose (0, 0) as the position of default-frame-alist. Nevertheless, the
first frame created is maybe 4cm from the left and 5cm from the top (and the
minibuffer frame is about 1cm from the left). So, the default-frame-alist
does not seem to be respected, wrt position.

Actually, it's weirder than that. The initial positions of the main frame
and the minibuffer frame seem to be inconsistent. At first I thought it
might depend on which other frames were open - even from a different Emacs
session. I iconified some existing sessions and then started a new Emacs
session, and the main frame was about 2cm from the left and 3cm from the
top; the minibuffer frame was about 3cm from the left. But I did that again,
and the positions were 2cm, 3cm for the main frame and 5cm for the
minibuffer frame. It's almost as if the last position of some frame (even
from another session, that might even be iconified now) were saved, and then
the next frame created was offset from that.

Previously, Emacs gave consistent and reasonable results for `make-frame' -
both Emacs 20 and previous Emacs 22 builds. Now, it seems that one doesn't
know what to expect. However, it's not random - something seems to be going
on in some way related to frames previously created (even in previous
sessions).

----

Now, I see that you (Eli) say that this new, inconsistent and unpredictable
behavior is a feature:

    With "emacs -Q", this is the intended behavior:
    the latest changes let the system locate the Emacs
    frame.  The original cause for the change
    was to avoid locating the Emacs frame in the
    portions of the screen occupied by the task bar
    and other decorations.

I understand the motivation, but I, for one, don't like this improvement one
bit. I don't remember seeing this design change discussed, BTW.

First, `default-frame-alist' should be rigorously respected - it seems to be
ignored wrt position now. Second, a user should not *need* to provide
position settings for `default-frame-alist' (or even to provide a
`default-frame-alist') in order to get consistent results when s?he opens
Emacs.

Windows apps generally do not behave in this inconsistent way, trying to
avoid the task bar - most simply open at 0,0. The new behavior seems silly,
and is quite annoying, IMO. If people don't laugh at it, they will curse at
it.

There should be a default value for top, left = 0,0, as before. Anything
else seems weird and unnatural. If the reason for this change was to avoid
the position of the task bar, then I would say:

- The cure is far worse than the disease.

- If there is a good way for Emacs to determine
  the task-bar position, then it could DTRT in
  this regard - *not* just leave positioning up
  to the window manager or the stars.

- If there is no good way for Emacs to determine
  the task-bar position, then it should position
  frames as before, and let the user, who can
  know the task bar position, deal with
  positioning frames to avoid it.

Here is the version I was testing:

In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
 of 2006-07-19 on BOS-CTHEWLAP2
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-msvc (12.00)'

Re: Emacs geometry

[Ralf Angeli]

* Drew Adams (2006-07-25) writes:

> I understand the motivation, but I, for one, don't like this improvement one
> bit. I don't remember seeing this design change discussed, BTW.

Look in emacs-pretest-bug.  The thread is called "startup frame
position".

> First, `default-frame-alist' should be rigorously respected - it seems to be
> ignored wrt position now.

Have you checked with the current source?

> There should be a default value for top, left = 0,0, as before. Anything
> else seems weird and unnatural.

Not one of the applications on Windows I know opens at (0,0).  They
either let the window manager do the placement or open with the
geometry they had in their last session.  That means opening at (0,0)
is rather weird an unnatural.

The cascading behavior there is now might need some love because Emacs
ends up for too often at the bottom of the screen.  But this looks
like a bug in the window manager.

> Here is the version I was testing:
>
> In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
>  of 2006-07-19 on BOS-CTHEWLAP2

Could you try with a more recent version?

-- 
Ralf

RE: Emacs geometry

[Drew Adams]

    > First, `default-frame-alist' should be rigorously respected -
    > it seems to be ignored wrt position now.

    Have you checked with the current source?

No. I tested with a version that is now 5 days old. It was 0 days old when I
was asked to test it (for a different frame-positioning bug, fixed by Fran),
and when I reported this bug (to Fran).

    > There should be a default value for top, left = 0,0, as
    > before. Anything else seems weird and unnatural.

    Not one of the applications on Windows I know opens at (0,0).  They
    either let the window manager do the placement or open with the
    geometry they had in their last session.  That means opening at (0,0)
    is rather weird an unnatural.

I just checked several, and I guess you're right & I was wrong. In most
cases I saw, they seemed to open where they were last closed, which means
that wherever the user positioned them last is respected - that's certainly
better than random or wherever the WM thinks is good.

    The cascading behavior there is now might need some love because Emacs
    ends up for too often at the bottom of the screen.  But this looks
    like a bug in the window manager.

I noticed that IE's cascading seems to be like this, which isn't too bad:
Start at 0,0 or the position of the last session, then, alternately a)
slightly down and to the right, and b) flush with the top but to the right.
When the display right edge is reached, then back to 0,0. IOW, it doesn't
keep going down - each frame is either flush with the top or slightly below
the top; continued cascading is only left to right.

    Could you try with a more recent version?

When I can get one, I will. If the default-frame-alist is respected, that
will be a big improvement - Emacs users need some way to control the
position of the first frame, in particular.

Otherwise, if the default behavior is like IE's, that would be good, IMO:
0,0, if no previous session, else same as last position (last session);
cascading right and alternately up and down.

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 25 Jul 2006 06:41:16 -0700
> 
>     Not one of the applications on Windows I know opens at (0,0).  They
>     either let the window manager do the placement or open with the
>     geometry they had in their last session.  That means opening at (0,0)
>     is rather weird an unnatural.
> 
> I just checked several, and I guess you're right & I was wrong. In most
> cases I saw, they seemed to open where they were last closed, which means
> that wherever the user positioned them last is respected - that's certainly
> better than random or wherever the WM thinks is good.

We could add code to record the last position in the registry, but I'd
postpone that to after the release.

> Otherwise, if the default behavior is like IE's, that would be good, IMO:
> 0,0, if no previous session, else same as last position (last session);
> cascading right and alternately up and down.

No, 0,0 is a bad choice for those who have the task bar there, we
should not go back to it.

RE: Emacs geometry

[Drew Adams]

    We could add code to record the last position in the registry, but I'd
    postpone that to after the release.

Why wouldn't that bug be fixed before the release? It is a result of an
incomplete bug fix (or incomplete feature addition).

The current behavior (random?) is worse than what existed before - it
*requires all* users to play with default-frame-alist or (worse!) to fiddle
with the registry, just to have some control over frame positioning.

If the aim was to move to the way other Windows apps behave, and so avoid
overlapping the task bar, then why not go all the way and do what the other
apps do: remember the last-session position, and restore it?

    > Otherwise, if the default behavior is like IE's, that would
    > be good, IMO: 0,0, if no previous session, else same as last
    > position (last session); cascading right and alternately
    > up and down.

    No, 0,0 is a bad choice for those who have the task bar there, we
    should not go back to it.

So what should the *default* position be, then, if there is no last-session
position to recover? Random? That seems broken, to me.

If I had to guess, I'd guess that 90% of Windows users leave the task bar in
its default position, at the bottom of the screen. Of the remaining 10%, how
many do you think put it at the top or the left of the screen? 1/3 = 3%?
Those few users can specify the position they want, instead of depending on
the default position - it is enough to position the frame once, and then
start a new session (provided that bug is fixed).

IOW, have a reasonable default position (= 0,0), and use that if the user
has specified no preference (either by default-frame-alist, or registry, or
last session's position). Minimize the number of users who will need to
override the default - bothering 3% is better than bothering 100%.

Finally, you didn't speak to my suggestion for cascading, instead of down,
down, down...

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 25 Jul 2006 11:56:59 -0700
> 
>     We could add code to record the last position in the registry, but I'd
>     postpone that to after the release.
> 
> Why wouldn't that bug be fixed before the release?

What bug?  Emacs never recorded the position in the registry, so what
you are asking for is a new feature, not a bugfix.

> It is a result of an incomplete bug fix (or incomplete feature
> addition).

If you mean the fact that the initial position is left to the window
manager, then it's _by_design_, it's not an omission, nor a bug.

> The current behavior (random?) is worse than what existed before

I disagree.  Other GUI applications, though not all, have this
behavior, and I don't find it annoying.  AFAIR, similar behaviors
exist on X with some window managers.

> - it
> *requires all* users to play with default-frame-alist or (worse!) to fiddle
> with the registry, just to have some control over frame positioning.

Only if you care about the position.  I don't see why you must.

Actually, with previous behavior, one would _always_ need to move
every frame but (perhaps) the first, because they all would overlap.
Now you don't need to do that.

> If the aim was to move to the way other Windows apps behave, and so avoid
> overlapping the task bar, then why not go all the way and do what the other
> apps do: remember the last-session position, and restore it?

Because we will never get a stable Emacs if we keep adding features.

> If I had to guess, I'd guess that 90% of Windows users leave the task bar in
> its default position, at the bottom of the screen. Of the remaining 10%, how
> many do you think put it at the top or the left of the screen? 1/3 = 3%?
> Those few users can specify the position they want, instead of depending on
> the default position - it is enough to position the frame once, and then
> start a new session (provided that bug is fixed).

This goes both ways--you are the only one who complained about the new
behavior, so by your logic we can just dismiss that as a miniscule
minority.

> Finally, you didn't speak to my suggestion for cascading, instead of down,
> down, down...

We don't tell Windows to move the position down, we just tell it to
use its own defaults.  If you, or someone else knows how to tell it to
cascade, please show the way, and we could consider that if it's not
too complicated.

RE: Emacs geometry

[Drew Adams]

    >     We could add code to record the last position in the
    >     registry, but I'd postpone that to after the release.
    >
    > Why wouldn't that bug be fixed before the release?

    What bug?  Emacs never recorded the position in the registry, so what
    you are asking for is a new feature, not a bugfix.

The random-positioning behavior is bad, and it didn't occur before. I call
that a bug.

    > It is a result of an incomplete bug fix (or incomplete feature
    > addition).

    If you mean the fact that the initial position is left to the window
    manager, then it's _by_design_, it's not an omission, nor a bug.

OK, so it's a design change. It's a bad design, and we never discussed it.

    > The current behavior (random?) is worse than what existed before

    I disagree.  Other GUI applications, though not all, have this
    behavior, and I don't find it annoying.  AFAIR, similar behaviors
    exist on X with some window managers.

Remembering where the user positioned an app last time, and using that
position next time (if no position is specified), is much better. A user
will appreciate that (and find it normal). No need to fiddle with
default-frame-alist or the registry: just position the frame where you want
it, and exit. That's pretty common on Windows.

    > - it *requires all* users to play with default-frame-alist or
    > (worse!) to fiddle with the registry, just to have some
    > control over frame positioning.

    Only if you care about the position.  I don't see why you must.

Well, let's see. How about having a random background color, and applying
the same argument: "Only if you care about background color. I don't see why
you must." Or, we could suddenly use a random font for the default: "Only if
you care about the font. I don't see why you must."

I must. No, you don't see why. Too bad.

    Actually, with previous behavior, one would _always_ need to move
    every frame but (perhaps) the first, because they all would overlap.
    Now you don't need to do that.

We're talking about the first frame only here, no? Default positioning of
subsequent frames would presumably be governed by a cascading scheme of some
sort - I proposed using the IE cascade model. In any case, this is about
positioning the first frame.

    > If the aim was to move to the way other Windows apps behave,
    > and so avoid overlapping the task bar, then why not go all
    > the way and do what the other apps do: remember the
    > last-session position, and restore it?

    Because we will never get a stable Emacs if we keep adding features.

So take out this feature, which was never discussed here, and we'll discuss
it for possible adoption after the release. If a half-baked feature is added
at the last minute, with no discussion, then it should either be fully baked
or backed out.

No, I don't consider discussion on emacs-pretest to be a substitute for
discussion here. This is a new feature, a new UI design. It changes
long-standing Emacs behavior, going back to the first Windows
implementation, AFAIK.

    > If I had to guess, I'd guess that 90% of Windows users leave
    > the task bar in its default position, at the bottom of the
    > screen. Of the remaining 10%, how many do you think put it
    > at the top or the left of the screen? 1/3 = 3%?
    > Those few users can specify the position they want, instead
    > of depending on the default position - it is enough to
    > position the frame once, and then
    > start a new session (provided that bug is fixed).

    This goes both ways--you are the only one who complained about the new
    behavior, so by your logic we can just dismiss that as a miniscule
    minority.

Ah, the old "you're the only one" argument, again. As you've seen before,
its persuasive power lasts only until the next person chimes in... Enjoy the
moment. Actually, two of us complained independently about this already; we
each reported it as a bug.

If you think my choice of default position is only individual, and does not
represent what most Windows users would expect as a default, then choose
another default position - as long as it is *constant* (so, consistent). I
can (and I already do) adjust my own setup - I'm not reasoning for my own
needs here, but for those of most Windows users.

It's the lack of a consistent default position that I'm arguing against.

I argued for 0,0 as the best default position, but you may have an argument
for a better position. What is it?

    > Finally, you didn't speak to my suggestion for cascading,
    > instead of down, down, down...

    We don't tell Windows to move the position down, we just tell it to
    use its own defaults.  If you, or someone else knows how to tell it to
    cascade, please show the way, and we could consider that if it's not
    too complicated.

No, sorry, I don't know how. My only experience of Windows is as a user. I
don't care so much about the cascading scheme. Someone else mentioned first
that it goes down, down, down. If we can do better, fine, but I can live
with down, down, down.

Re: Emacs geometry

[Jason Rumney]

Drew Adams wrote:
> The random-positioning behavior is bad,

It would be if it really was random, but I very much doubt that Windows 
calls random() to calculate the default position for windows. More 
likely it is based on the positions of previous windows you have opened.

IMHO there are many more important bugs that should be fixed before we 
spend more unproductive time arguing about whether this needs to be 
"fixed" or reverted before release.

RE: Emacs geometry

[Drew Adams]

    > The random-positioning behavior is bad,

    It would be if it really was random, but I very much doubt that Windows
    calls random() to calculate the default position for windows. More
    likely it is based on the positions of previous windows you have opened.

The point is that it is seemingly random; it is unpredictable - the *user*
doesn't know what to expect. We're dealing with deterministic software and
hardware, for the most part, but if the user hasn't a clue what's going on,
the behavior seems random - it makes no sense.

    IMHO there are many more important bugs that should be fixed before we
    spend more unproductive time arguing about whether this needs to be
    "fixed" or reverted before release.

I don't fix the priorities. I'm simply saying that this (too) should be
fixed before the release. Or else we should back it out, and discuss the
design and how to finish the job, after the release.

Re: Emacs geometry

[Sridhar Boovaraghavan]

I just want to acknowledge Drew for taking up the cudgels on my behalf here. In
these posts he has articulated what I feel. To reiterate:

1. I feel that the new offsetting frame behavior to be a bug.
2. If it is a feature as some have argued, I don't like that as a default.
Granted, I can get my old behavior back, but I feel that the old behavior is a
better default. The argument that some people might have their task bar there
doesn't mean that it is not a good default (clearly, it is not perfect) - such
people can change their settings.
3. If the user has repositioned the emacs window before exiting, then I may be
persuaded to see it coming back to that position when restarted given no other
settings like +0+0 or a defined Left/Top. Even if so, what if he had two frames
open while exiting - do we keep the position of the frame that had the focus as
where emacs would come up - maybe there are other similar questions that need to
be discussed.
4. If the user specifies HxW+X+Y in Emacs.Geometry, how about populating
default-frame-alist with those values (given that he doesn't specify another
value for it through his .emacs or .custom)?

Regards,
Sridhar

Re: Emacs geometry

[Eli Zaretskii]

> From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> Date: Wed, 26 Jul 2006 04:57:05 +0000 (UTC)
> 
> 3. If the user has repositioned the emacs window before exiting, then I may be
> persuaded to see it coming back to that position when restarted given no other
> settings like +0+0 or a defined Left/Top. Even if so, what if he had two frames
> open while exiting - do we keep the position of the frame that had the focus as
> where emacs would come up - maybe there are other similar questions that need to
> be discussed.

You see, this is only the tip of the iceberg; there are other related
issues that need to be discussed, decided, implemented, tested,
rewritten according to users' bug/misfeatures reports, tested again,
etc.  For example: what do we do under "emacs -Q"? do we honor the
previous recorded values or ignore them? how about "emacs -Q -D"?
Etc., etc.

Finally, Emacs doesn't behave like that on other platforms (AFAIK),
i.e. it doesn't come up where you positioned it the last time, so
this would be a deviation from the common behavior principle.

This is why I think now is not the time to implement such a feature.

> 4. If the user specifies HxW+X+Y in Emacs.Geometry, how about populating
> default-frame-alist with those values (given that he doesn't specify another
> value for it through his .emacs or .custom)?

H and W _do_ get into default-frame-alist, as the `height' and `width'
frame paramaters; if this doesn't work for you, please report that as
a bug.  X and Y are only put into the initial-frame-alist, because the
idea is that these two geometry parameters are meant only for the
initial frame.  (The fact that the Windows port of Emacs currently
ignores X and Y is a bug that should be fixed: we did obey them in
version 21.4.)

RE: Emacs geometry

[Drew Adams]

    You see, this is only the tip of the iceberg; there are other related
    issues that need to be discussed, decided, implemented, tested,
    rewritten according to users' bug/misfeatures reports, tested again,
    etc.  For example: what do we do under "emacs -Q"? do we honor the
    previous recorded values or ignore them? how about "emacs -Q -D"?
    Etc., etc.

Bravo, Eli! I couldn't agree more.

    This is why I think now is not the time to implement such a feature.

That applies to this new feature in general: changing how Emacs frames are
positioned on Windows. This is why we should back out the change that was
made, and revert to the previous behavior, which everyone has used without
complaint for decades.

If we want to improve on that traditional behavior, making it somehow smart
enough to deal with avoiding the task bar, yet still remain predictable,
consistent, and under user control (without contortions such as tweaking the
registry), then we can discuss how to do that *after the release*. This
partial cure to a minor potential problem is much worse than the perceived
disease itself, and it was never properly discussed.

Now is not the time to change fundamental behavior like this. You already
got two strong complaints within weeks of making the change. If you keep
this change, you will see how many Windows users complain or exclaim
"HUH?!".

Re: Emacs geometry

[Jason Rumney]

Sridhar Boovaraghavan wrote:
> I just want to acknowledge Drew for taking up the cudgels on my behalf here. In
> these posts he has articulated what I feel. To reiterate:
>
> 1. I feel that the new offsetting frame behavior to be a bug.
>   

On the contrary, it is now consistent with what happens on X if no 
position is explicitly supplied by the user - the window manager is left 
to position the frame.
The previous behavior of positioning the frame at (0, 0), while it has 
been around for a long time, was a bug, and since it produces bad 
results when the taskbar is at the top of the screen, it was appropriate 
to fix the bug.

RE: Emacs geometry

[Drew Adams]

    On the contrary, it is now consistent with what happens on X if no
    position is explicitly supplied by the user - the window
    manager is left
    to position the frame.
    The previous behavior of positioning the frame at (0, 0), while it has
    been around for a long time, was a bug, and since it produces bad
    results when the taskbar is at the top of the screen, it was
    appropriate
    to fix the bug.

Please, someone tell me how many Windows users reposition their task bar to
the *top* of the screen? For the 3 users worldwide who might do that: they
can use default-frame-alist or hack the registry to solve their "problem" -
please save the rest of the users that trouble.

Re: Emacs geometry

[Mathias Dahl]

> Please, someone tell me how many Windows users reposition their task bar to
> the *top* of the screen?

I do :), for two reasons:

 - Been used to it from how my Gnome was configured by default.
 - When I bought an old 21 inch monitor for work ($10), having the
taskbar at the top was better.

I haven't been following this thread so I have no idea what you are
discussing though. If I start emacs with -Q I sometimes get annoyed
(the same with a lot of w32-programs) that the window's top border is
hidden behind Window's taskbar. But I have learnt to live with it. I
do RMB -> Move on the program in the taskbar and move using the arrow
keys.

Re: Emacs geometry

[Jason Rumney]

Drew Adams wrote:
> Please, someone tell me how many Windows users reposition their task bar to
> the *top* of the screen?
Probably more than care where exactly on the screen their Emacs frames 
appear, and insist that it is not they who should have to configure the 
initial position of their Emacs frame.

> For the 3 users worldwide who might do that: they
> can use default-frame-alist or hack the registry to solve their "problem"

The Emacs title-bar being off the usable portion of the screen is a 
genuine problem. While it is possible to manually move such frames, it 
is not obvious, and many users may not be familiar with the procedure.

The desire to have Emacs appear in the same place every time without 
explicitly configuring it to do so is *not* a genuine problem. You are 
just ranting Drew, please stop!

RE: Emacs geometry

[Drew Adams]

    > I don't remember seeing this design change discussed, BTW.

    Look in emacs-pretest-bug.  The thread is called "startup frame
    position".

I see. This change seems more like a design change than just a bug fix. I
would have expected it to be discussed in emacs-devel. I guess it is, now
;-).

Anyway, as I say, if default-frame-alist is respected, I can live with it.
And, it would be good to have a default of 0,0 or last position, rather than
just whatever the gods happen to will that morning.

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 25 Jul 2006 08:20:42 +0200
> 
> * Drew Adams (2006-07-25) writes:
> 
> > I understand the motivation, but I, for one, don't like this improvement one
> > bit. I don't remember seeing this design change discussed, BTW.
> 
> Look in emacs-pretest-bug.  The thread is called "startup frame
> position".
> 
> > First, `default-frame-alist' should be rigorously respected - it seems to be
> > ignored wrt position now.
> 
> Have you checked with the current source?

Sridhar Boovaraghavan reports that geometry specification in the
Registry is not honored.  If that is true, it's a bug that should be
fixed.  Could you please look into it?

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-25) writes:

> Sridhar Boovaraghavan reports that geometry specification in the
> Registry is not honored.  If that is true, it's a bug that should be
> fixed.  Could you please look into it?

Sure.  But likely not today.

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 25 Jul 2006 20:55:35 +0200
> 
> * Eli Zaretskii (2006-07-25) writes:
> 
> > Sridhar Boovaraghavan reports that geometry specification in the
> > Registry is not honored.  If that is true, it's a bug that should be
> > fixed.  Could you please look into it?
> 
> Sure.  But likely not today.

Thanks.

Here's what I saw in the code, that would perhaps help you.  When
Emacs sees -geometry, it puts the width and height parameters into
both default-frame-alist and initial-frame-alist, but top and left
only into initial-frame-alist.  (See w32-win.el: x-handle-geometry.)
Later, when w32_createwindow is called to create the initial frame, it
calls w32_get_arg to get the left and top coordinates, but it calls it
with the first argument Qnil.  When called with Qnil, w32_get_arg
looks inside default-frame-alist, but the left and top parameters are
not there.  So we use CW_USEDEFAULT instead.

The trick is to somehow recognize that this is the initial frame, and
then call w32_get_arg to look up left and top in initial-frame-alist,
not just in default-frame-alist.

Re: Emacs geometry

[Eli Zaretskii]

> Date: Tue, 25 Jul 2006 22:58:48 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> The trick is to [...] call w32_get_arg to look up left and top in
> initial-frame-alist

Sorry, this part was bad advice: you cannot look up left and top in
initial-frame-alist, you should instead honor f->left_pos and
f->top_pos, if they were set from initial-frame-alist.  The problem is
to decide correctly when to honor them.

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-25) writes:

>> Date: Tue, 25 Jul 2006 22:58:48 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> The trick is to [...] call w32_get_arg to look up left and top in
>> initial-frame-alist
>
> Sorry, this part was bad advice: you cannot look up left and top in
> initial-frame-alist,

Hm, couldn't one get the value from the Lisp level?

> you should instead honor f->left_pos and
> f->top_pos, if they were set from initial-frame-alist.  The problem is
> to decide correctly when to honor them.

One could probably use the
  if (!hprevinst)
test in w32_createwindow in order to decide if it's the first frame to
be created, but how can one decide if there are values for `top' and
`left' which are only relevant for the first frame?  That's where
`initial-frame-alist' would really come in handy.  I guess I'll need a
little bit more time for this.

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Thu, 27 Jul 2006 23:58:47 +0200
> 
> >> The trick is to [...] call w32_get_arg to look up left and top in
> >> initial-frame-alist
> >
> > Sorry, this part was bad advice: you cannot look up left and top in
> > initial-frame-alist,
> 
> Hm, couldn't one get the value from the Lisp level?

Of course, you could: use `intern'.  But I suspect that, by the time
w32_createwindow runs, the left and top frame parameters were already
removed from initial-frame-alist and put into the `top_pos' and
`left_pos' members of struct frame that is passed to w32_createwindow.
But please verify that, I could be wrong.

> > you should instead honor f->left_pos and
> > f->top_pos, if they were set from initial-frame-alist.  The problem is
> > to decide correctly when to honor them.
> 
> One could probably use the
>   if (!hprevinst)
> test in w32_createwindow in order to decide if it's the first frame to
> be created, but how can one decide if there are values for `top' and
> `left' which are only relevant for the first frame?

I didn't figure out that bit yet.  One thing to try is trace the
execution from the point where w32-win.el puts the values into
initial-frame-alist and till the call to w32_createwindow, and see if
that gives you any ideas.

> That's where `initial-frame-alist' would really come in handy.

I think when w32_createwindow is called, the contents of
initial-frame-alist are in f->params_alist.  So accessing that is
easy.  The problem is, the left and top parameters are not there.

Maybe if you compare f->top_pos and f->left_pos with the corresponding
frame parameters in f->params_alist, for different calls to
w32_createwindow, you will see how to identify that the initial frame
is being created.

> I guess I'll need a little bit more time for this.

There's no hurry.  Thanks.

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-28) writes:

>> > Sorry, this part was bad advice: you cannot look up left and top in
>> > initial-frame-alist,
>> 
>> Hm, couldn't one get the value from the Lisp level?
>
> Of course, you could: use `intern'.  But I suspect that, by the time
> w32_createwindow runs, the left and top frame parameters were already
> removed from initial-frame-alist and put into the `top_pos' and
> `left_pos' members of struct frame that is passed to w32_createwindow.
> But please verify that, I could be wrong.

Hm, something seems to be there.  If I insert

  Lisp_Object foo = Qnil;
  foo = Fsymbol_value (intern ("initial-frame-alist"));
  if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
    printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
	    XCDR (Fassq (Qleft, foo)));
  else
    printf ("no");

into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
top: 80, left: 160
appears in the shell.  Does anybody know why the output is eight times
the input?

Thanks for the valuable hints so far.

-- 
Ralf

Re: Emacs geometry

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Eli Zaretskii (2006-07-28) writes:
>
>>> > Sorry, this part was bad advice: you cannot look up left and top in
>>> > initial-frame-alist,
>>> 
>>> Hm, couldn't one get the value from the Lisp level?
>>
>> Of course, you could: use `intern'.  But I suspect that, by the time
>> w32_createwindow runs, the left and top frame parameters were already
>> removed from initial-frame-alist and put into the `top_pos' and
>> `left_pos' members of struct frame that is passed to w32_createwindow.
>> But please verify that, I could be wrong.
>
> Hm, something seems to be there.  If I insert
>
>   Lisp_Object foo = Qnil;
>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
> 	    XCDR (Fassq (Qleft, foo)));
>   else
>     printf ("no");
>
> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
> top: 80, left: 160
> appears in the shell.  Does anybody know why the output is eight times
> the input?

Because a character cell is 8 pixels wide?  If that is the reason, I
think it is a mistake: the +/- values obviously don't make sense other
than as pixel values.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sun, 30 Jul 2006 22:30:14 +0200
> 
> Hm, something seems to be there.  If I insert
> 
>   Lisp_Object foo = Qnil;
>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
> 	    XCDR (Fassq (Qleft, foo)));
>   else
>     printf ("no");
> 
> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
> top: 80, left: 160
> appears in the shell.  Does anybody know why the output is eight times
> the input?

Probably because -geometry is specified in character units, while top
and left are in pixels.

Re: Emacs geometry

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Sun, 30 Jul 2006 22:30:14 +0200
>> 
>> Hm, something seems to be there.  If I insert
>> 
>>   Lisp_Object foo = Qnil;
>>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
>> 	    XCDR (Fassq (Qleft, foo)));
>>   else
>>     printf ("no");
>> 
>> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
>> top: 80, left: 160
>> appears in the shell.  Does anybody know why the output is eight times
>> the input?
>
> Probably because -geometry is specified in character units, while top
> and left are in pixels.

(info "(emacs) Window Size X")

    Here is a list of the command-line options for specifying size and
    position of the initial Emacs frame:

    `-g WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
    `--geometry=WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
         Specify the size WIDTH and HEIGHT (measured in character columns
         and lines), and positions XOFFSET and YOFFSET (measured in
         pixels).  This applies to all frames.

Incidentally, is it correct that the offsets would apply to all
frames?  Seems somewhat impractical since it would let all frames open
on the same location.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs geometry

[Eli Zaretskii]

> Cc: Ralf Angeli <angeli@caeruleus.net>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sun, 30 Jul 2006 22:48:30 +0200
> 
> Incidentally, is it correct that the offsets would apply to all
> frames?

No.

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sun, 30 Jul 2006 22:30:14 +0200
> 
>   Lisp_Object foo = Qnil;
>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
> 	    XCDR (Fassq (Qleft, foo)));
>   else
>     printf ("no");
> 
> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
> top: 80, left: 160
> appears in the shell.

Interesting.  And what is the value of f->param_alist at that point?

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-30) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Sun, 30 Jul 2006 22:30:14 +0200
>> 
>>   Lisp_Object foo = Qnil;
>>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
>> 	    XCDR (Fassq (Qleft, foo)));
>>   else
>>     printf ("no");
>> 
>> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
>> top: 80, left: 160
>> appears in the shell.
>
> Interesting.  And what is the value of f->param_alist at that point?

I've got no idea.  As far as I understand f->param_alist has the same
structure as initial-frame-alist.  But if I try to get the values for
top and left with stuff like XCDR (Fassq (Qtop, f->param_alist)), all
I get are (identical) addresses as it seems.  For example
top: 18179347, left 18179347
If I try to dereference those with * I get an error during compile.

BTW, I don't get any output if I try to use macros like XCDR or XCAR
with gdb.  Am I doing something wrong?  As far as I understood the
manual of gdb it should be able to handle those.

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sun, 30 Jul 2006 23:09:33 +0200
> 
> > Interesting.  And what is the value of f->param_alist at that point?
> 
> I've got no idea.

You could look in the debugger.

> As far as I understand f->param_alist has the same
> structure as initial-frame-alist.  But if I try to get the values for
> top and left with stuff like XCDR (Fassq (Qtop, f->param_alist)), all
> I get are (identical) addresses as it seems.  For example
> top: 18179347, left 18179347

Try xtype and/or pr right after you print that in the debugger.  I'm
guessing that this is nil (a.k.a. Qnil in C), which would mean that
there's no left and top parameters in f->param_alist.

> BTW, I don't get any output if I try to use macros like XCDR or XCAR
> with gdb.  Am I doing something wrong?

Yes, see etc/DEBUG.  We have special commands (defined in .gdbinit) to
print Lisp objects.

> As far as I understood the manual of gdb it should be able to handle
> those.

Only if you compile with "-gdwarf-2 -g3", and even then I'm not sure
this is supported on Windows.

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-30) writes:

> Yes, see etc/DEBUG.  We have special commands (defined in .gdbinit) to
> print Lisp objects.

I've always been wondering how you use .gdbinit under Windows because
there is no executable in the src directory.  And if I try to source
.gdbinit from gdb I get the backtrace

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("//+" nil)
  gud-find-file(nil)
  gdb-set-hollow()
  gdb-prompt("")
  gud-gdba-marker-filter([...])
  apply([...])
  gud-marker-filter([...])
  gud-filter(#<process gud-emacs.exe> [...])

as soon as I type "run".

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sun, 30 Jul 2006 23:46:41 +0200
> 
> I've always been wondering how you use .gdbinit under Windows because
> there is no executable in the src directory.

>From the command line:

  gdb ../bin/emacs.exe

(or similar, if emacs.exe is not in src/../bin on your system).

>  And if I try to source .gdbinit from gdb I get the backtrace
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   string-match("//+" nil)
>   gud-find-file(nil)
>   gdb-set-hollow()
>   gdb-prompt("")
>   gud-gdba-marker-filter([...])
>   apply([...])
>   gud-marker-filter([...])
>   gud-filter(#<process gud-emacs.exe> [...])
> 
> as soon as I type "run".

I'm guessing that you run GDB via "M-x gdba".  In that case, this
could be a bug in gdb-ui.el, although when I try that now, I cannot
reproduce this problem.  Does it happen to you with "emacs -Q"?

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-31) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> Date: Sun, 30 Jul 2006 23:46:41 +0200
>> 
>> I've always been wondering how you use .gdbinit under Windows because
>> there is no executable in the src directory.
>
>>From the command line:
>
>   gdb ../bin/emacs.exe
>
> (or similar, if emacs.exe is not in src/../bin on your system).

There is not emacs.exe in my source tree after I build Emacs.  There
is only one in the target installation directory
(c:/Programme/Emacs/bin in my case) after `make install' was run
(which is actually a bit annoying).

>>  And if I try to source .gdbinit from gdb I get the backtrace
>> 
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   string-match("//+" nil)
>>   gud-find-file(nil)
>>   gdb-set-hollow()
>>   gdb-prompt("")
>>   gud-gdba-marker-filter([...])
>>   apply([...])
>>   gud-marker-filter([...])
>>   gud-filter(#<process gud-emacs.exe> [...])
>> 
>> as soon as I type "run".
>
> I'm guessing that you run GDB via "M-x gdba".

It's `M-x gdb' to be precise.  Sorry for not writing that beforehand.

> In that case, this
> could be a bug in gdb-ui.el, although when I try that now, I cannot
> reproduce this problem.  Does it happen to you with "emacs -Q"?

Yes.  But maybe I am using the interface in an invalid way.  What I've
done is

* starting Emacs with `emacs -Q'
* changing directory with `C-x C-f c:/Programme/Emacs/bin'
* starting GDB with `M-x gdb RET' and using `emacs.exe' as the
  executable to debug
* loading .gdbinit from GDB with `source /path/to/.gdbinit'
* setting a breakpoint with `b w32_createwindow'
* running Emacs with `run -g 80x30+10+20'

I don't get a backtrace if I start GDB in the source tree where
.gdbinit resides and then use the `emacs.exe' executable from the
installation directory for GDB.  But the `xtype' and `pr' commands
don't seem to work either:

(gdb) p Fassq (Qtop, f->param_alist)
$1 = 23713793
(gdb) pr
(gdb) xtype
(gdb)

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Mon, 31 Jul 2006 21:06:29 +0200
> 
> >>From the command line:
> >
> >   gdb ../bin/emacs.exe
> >
> > (or similar, if emacs.exe is not in src/../bin on your system).
> 
> There is not emacs.exe in my source tree after I build Emacs.  There
> is only one in the target installation directory
> (c:/Programme/Emacs/bin in my case) after `make install' was run
> (which is actually a bit annoying).

Then type "gdb c:/Programme/Emacs/bin/emacs.exe" instead.

> * starting Emacs with `emacs -Q'
> * changing directory with `C-x C-f c:/Programme/Emacs/bin'
> * starting GDB with `M-x gdb RET' and using `emacs.exe' as the
>   executable to debug
> * loading .gdbinit from GDB with `source /path/to/.gdbinit'
> * setting a breakpoint with `b w32_createwindow'
> * running Emacs with `run -g 80x30+10+20'

This is perfectly valid usage, so if you get a Lisp backtrace, I
suggest to debug that, or at least post a reproducible recipe.  FWIW,
I don't see an error when I follow this recipe (as close as my
different installation allows).

> I don't get a backtrace if I start GDB in the source tree where
> .gdbinit resides and then use the `emacs.exe' executable from the
> installation directory for GDB.

Another sign of a bug, if you ask me.

> But the `xtype' and `pr' commands don't seem to work either:

`pr' is tricky; I'm guessing that the Windows pipe emulation on the
Emacs side and the console output on the GDB side don't work together
well enough for `pr' to work from within Emacs.  (`pr' does work for
me if I invoke GDB from the Command Prompt window outside Emacs.)  Use
`xtype' to see the type and xint, xsymbol, xcar, etc., according to
what xtype prints, to see the value.

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-31) writes:

> `pr' is tricky; I'm guessing that the Windows pipe emulation on the
> Emacs side and the console output on the GDB side don't work together
> well enough for `pr' to work from within Emacs.  (`pr' does work for
> me if I invoke GDB from the Command Prompt window outside Emacs.)  Use
> `xtype' to see the type and xint, xsymbol, xcar, etc., according to
> what xtype prints, to see the value.

Phew, finally! (c:

(gdb) p Fassq (Qtop, f->param_alist)
$1 = 23713793
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x169d800
"nil"
(gdb)

That was done withing a MinGW shell.  `pr' isn't working in that shell
either.

Now as there doesn't seem to be anything in f->param_alist regarding
top or left I guess we can go for `initial-frame-alist'.

I'll look at the problems with gud.el as soon as I find time for it.

-- 
Ralf

Re: Emacs geometry

[Nick Roberts]

 > > `pr' is tricky; I'm guessing that the Windows pipe emulation on the
 > > Emacs side and the console output on the GDB side don't work together
 > > well enough for `pr' to work from within Emacs.  (`pr' does work for
 > > me if I invoke GDB from the Command Prompt window outside Emacs.)  Use
 > > `xtype' to see the type and xint, xsymbol, xcar, etc., according to
 > > what xtype prints, to see the value.
 > 
 > Phew, finally! (c:
 > 
 > (gdb) p Fassq (Qtop, f->param_alist)
 > $1 = 23713793
 > (gdb) xtype
 > Lisp_Symbol
 > (gdb) xsymbol
 > $2 = (struct Lisp_Symbol *) 0x169d800
 > "nil"
 > (gdb)
 > 
 > That was done withing a MinGW shell.  `pr' isn't working in that shell
 > either.

I think Eli is right as to why, `pr' actually prints by executing Emacs.  The
commentary in gdb-ui.el has something about how to make the output stream
unbuffered (Note: I don't use Windows, it's just advice someone else gave me).

>From your earlier e-mail:

>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   string-match("//+" nil)
>>   gud-find-file(nil)
>>   gdb-set-hollow()
>>   gdb-prompt("")
>>   gud-gdba-marker-filter([...])
>>   apply([...])
>>   gud-marker-filter([...])
>>   gud-filter(#<process gud-emacs.exe> [...])

I'm a bit baffled because gdb-prompt doesn't call gdb-set-hollow, only
gdb-info-stack-custom does.  I've recently changed the code (yesterday)
so this part doesn't get called by default so you may have to set
gdb-find-source-frame to t to reproduce it.

If you do move the executable (as with "make install") you need to be sure
that GDB can still find the source (some debug formats store the information,
others don't).  Starting GDB in the source tree means GDB will find the
source because it looks in the current directory.

If you do:

* starting GDB from the command line and using `emacs.exe' as the
                        ************
  executable to debug
* loading .gdbinit from GDB with `source /path/to/.gdbinit'
* setting a breakpoint with `b w32_createwindow'
* running Emacs with `run -g 80x30+10+20'

Does it say something like?:

2071      w32fns.c: No such file or directory.
          in w32fns.c

Even so Emacs should say the same thing and not generate a backtrace.  Can
you find out how gdb-set-hollow gets called e.g do debug-on-entry there,
or Edebug on gdb-prompt?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs geometry

[Nick Roberts]

 > >From your earlier e-mail:
 > 
 > >> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 > >>   string-match("//+" nil)
 > >>   gud-find-file(nil)
 > >>   gdb-set-hollow()
 > >>   gdb-prompt("")
 > >>   gud-gdba-marker-filter([...])
 > >>   apply([...])
 > >>   gud-marker-filter([...])
 > >>   gud-filter(#<process gud-emacs.exe> [...])
 > 
 > I'm a bit baffled because gdb-prompt doesn't call gdb-set-hollow, only
 > gdb-info-stack-custom does.  I've recently changed the code (yesterday)
 > so this part doesn't get called by default so you may have to set
 > gdb-find-source-frame to t to reproduce it.

So I spoke too quickly.  The backtrace makes sense and I've installed a fix.

You still need to arrange for GDB to see the source.  You can also do this by
adding the path to the source with the `dir' command.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs geometry

[Ralf Angeli]

* Nick Roberts (2006-08-01) writes:

>  > I'm a bit baffled because gdb-prompt doesn't call gdb-set-hollow, only
>  > gdb-info-stack-custom does.  I've recently changed the code (yesterday)
>  > so this part doesn't get called by default so you may have to set
>  > gdb-find-source-frame to t to reproduce it.
>
> So I spoke too quickly.  The backtrace makes sense and I've installed a fix.

Confirmed.  Thanks!

> You still need to arrange for GDB to see the source.  You can also do this by
> adding the path to the source with the `dir' command.

GDB (or gud.el, I haven't checked) doesn't have a problem finding the
source on my system.

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 01 Aug 2006 19:55:32 +0200
> 
> > You still need to arrange for GDB to see the source.  You can also do this by
> > adding the path to the source with the `dir' command.
> 
> GDB (or gud.el, I haven't checked) doesn't have a problem finding the
> source on my system.

Probably because the source location is recorded in the debug info
within the executable.

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Mon, 31 Jul 2006 23:37:37 +0200
> 
> (gdb) p Fassq (Qtop, f->param_alist)
> $1 = 23713793
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0x169d800
> "nil"
> (gdb)
> 
> That was done withing a MinGW shell.  `pr' isn't working in that shell
> either.

It does for me.  What version of GDB are you using, and where did you
download it from?

> Now as there doesn't seem to be anything in f->param_alist regarding
> top or left I guess we can go for `initial-frame-alist'.

Yes.

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-08-01) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>> 
>> `pr' isn't working in that shell
>> either.
>
> It does for me.  What version of GDB are you using, and where did you
> download it from?

$ gdb --version
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
[...]

from mingw.org.

-- 
Ralf

Re: Emacs geometry

[Ralf Angeli]

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

* Eli Zaretskii (2006-08-01) writes:

>> From: Ralf Angeli <angeli@caeruleus.net>
>
>> Now as there doesn't seem to be anything in f->param_alist regarding
>> top or left I guess we can go for `initial-frame-alist'.
>
> Yes.

Okay, here is the patch:

2006-08-01  Ralf Angeli  <angeli@caeruleus.net>

	* w32fns.c (w32_createwindow): Handle geometry command line option
	and registry key.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1475 bytes --]

--- w32fns.c	27 Jul 2006 22:00:10 +0200	1.272
+++ w32fns.c	01 Aug 2006 22:02:00 +0200	
@@ -2066,7 +2066,8 @@
 {
   HWND hwnd;
   RECT rect;
-  Lisp_Object top, left;
+  Lisp_Object top = Qunbound;
+  Lisp_Object left = Qunbound;
 
   rect.left = rect.top = 0;
   rect.right = FRAME_PIXEL_WIDTH (f);
@@ -2079,13 +2080,27 @@
 
   if (!hprevinst)
     {
+      Lisp_Object ifa;
+
       w32_init_class (hinst);
+
+      /* Handle geometry command line option and registry key. */
+      ifa = Fsymbol_value (intern ("initial-frame-alist"));
+      if (CONSP (ifa) && Fassq (Qleft, ifa)
+	  && INTEGERP (XCDR (Fassq (Qleft, ifa))))
+	left = XCDR (Fassq (Qleft, ifa));
+      if (CONSP (ifa) && Fassq (Qtop, ifa)
+	  && INTEGERP (XCDR (Fassq (Qtop, ifa))))
+	top = XCDR (Fassq (Qtop, ifa));
     }
 
-  /* When called with RES_TYPE_NUMBER, w32_get_arg will return zero
-     for anything that is not a number and is not Qunbound.  */
-  left = w32_get_arg (Qnil, Qleft, "left", "Left", RES_TYPE_NUMBER);
-  top = w32_get_arg (Qnil, Qtop, "top", "Top", RES_TYPE_NUMBER);
+  if (EQ (left, Qunbound) && EQ (top, Qunbound))
+    {
+      /* When called with RES_TYPE_NUMBER, w32_get_arg will return zero
+	 for anything that is not a number and is not Qunbound.  */
+      left = w32_get_arg (Qnil, Qleft, "left", "Left", RES_TYPE_NUMBER);
+      top = w32_get_arg (Qnil, Qtop, "top", "Top", RES_TYPE_NUMBER);
+    }
 
   FRAME_W32_WINDOW (f) = hwnd
     = CreateWindow (EMACS_CLASS,

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]


-- 
Ralf

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 01 Aug 2006 22:09:26 +0200
> 
> * Eli Zaretskii (2006-08-01) writes:
> 
> >> From: Ralf Angeli <angeli@caeruleus.net>
> >
> >> Now as there doesn't seem to be anything in f->param_alist regarding
> >> top or left I guess we can go for `initial-frame-alist'.
> >
> > Yes.
> 
> Okay, here is the patch:
> 
> 2006-08-01  Ralf Angeli  <angeli@caeruleus.net>
> 
> 	* w32fns.c (w32_createwindow): Handle geometry command line option
> 	and registry key.

Thanks; installed.

Btw, the fact that you look at initial-frame-alist only when hprevinst
is zero doesn't seem to prevent that code from being run for every
frame; what saves the day is that initial-frame-alist no longer a cons
cell.  Is it expected that hprevinst is zero for subsequent frames?

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-08-04) writes:

> Btw, the fact that you look at initial-frame-alist only when hprevinst
> is zero doesn't seem to prevent that code from being run for every
> frame; what saves the day is that initial-frame-alist no longer a cons
> cell.  Is it expected that hprevinst is zero for subsequent frames?

That's how I interpreted the comment "Do first time app init" before
it.  Now I see that the variable is not touched by Emacs and on the
net there is only information about `hPrevInst' (which seems to be
obsolete on Windows32).  Is that equivalent to `hprevinst'?

Anyway, if testing `hprevinst' is useless we could move the new code
out of the if-clause (and probably think about a working test for the
w32_init_class call unless it needs to be called for every frame).

BTW, I saw you added two new variables `lt' and `tp' compared to my
original patch.  Is this because INTEGERP does not handle Qnil
(correctly)?

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Sat, 05 Aug 2006 16:05:46 +0200
> 
> BTW, I saw you added two new variables `lt' and `tp' compared to my
> original patch.  Is this because INTEGERP does not handle Qnil
> (correctly)?

Your code was correct, it's just that it called Fassq 3 times to get
the same value time and again.

Re: Emacs geometry

[Kim F. Storm]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Eli Zaretskii (2006-07-28) writes:
>
>>> > Sorry, this part was bad advice: you cannot look up left and top in
>>> > initial-frame-alist,
>>> 
>>> Hm, couldn't one get the value from the Lisp level?
>>
>> Of course, you could: use `intern'.  But I suspect that, by the time
>> w32_createwindow runs, the left and top frame parameters were already
>> removed from initial-frame-alist and put into the `top_pos' and
>> `left_pos' members of struct frame that is passed to w32_createwindow.
>> But please verify that, I could be wrong.
>
> Hm, something seems to be there.  If I insert
>
>   Lisp_Object foo = Qnil;
>   foo = Fsymbol_value (intern ("initial-frame-alist"));
>   if (CONSP (foo) && Fassq (Qtop, foo) && Fassq (Qleft, foo))
>     printf ("top: %d, left: %d", XCDR (Fassq (Qtop, foo)),
> 	    XCDR (Fassq (Qleft, foo)));

Does this give correct results?

    printf ("top: %d, left: %d", XINT (XCDR (Fassq (Qtop, foo))),
	    XINT (XCDR (Fassq (Qleft, foo))));

>   else
>     printf ("no");
>
> into `w32_createwindow' and call Emacs with -g 80x30+20+10 the output
> top: 80, left: 160
> appears in the shell.  Does anybody know why the output is eight times
> the input?
>
> Thanks for the valuable hints so far.
>
> -- 
> Ralf

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs geometry

[Ralf Angeli]

* Kim F. Storm (2006-07-31) writes:

> Does this give correct results?
>
>     printf ("top: %d, left: %d", XINT (XCDR (Fassq (Qtop, foo))),
> 	    XINT (XCDR (Fassq (Qleft, foo))));

Yes, this prints the correct values.  Thanks!  Is there a general rule
about when to call XINT?

-- 
Ralf

Re: Emacs geometry

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Kim F. Storm (2006-07-31) writes:
>
>> Does this give correct results?
>>
>>     printf ("top: %d, left: %d", XINT (XCDR (Fassq (Qtop, foo))),
>> 	    XINT (XCDR (Fassq (Qleft, foo))));
>
> Yes, this prints the correct values.  Thanks!  Is there a general rule
> about when to call XINT?

Whenever one wants to convert a Lisp integer to a C integer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs geometry

[Stefan Monnier]

>> Does this give correct results?
>> 
>> printf ("top: %d, left: %d", XINT (XCDR (Fassq (Qtop, foo))),
>> XINT (XCDR (Fassq (Qleft, foo))));

> Yes, this prints the correct values.  Thanks!  Is there a general rule
> about when to call XINT?

If you compile with -DUSE_LISP_UNION_TYPE the compiler will tell you,


        Stefan


PS: Lisp_Object is often represented by an integer for efficiency reasons
    (i.e. because C compilers don't implement word-sized structs and unions
    efficiently enough), but that doesn't have to be the case.

Re: Emacs geometry

[Ralf Angeli]

* Stefan Monnier (2006-07-31) writes:

>> Is there a general rule
>> about when to call XINT?
>
> If you compile with -DUSE_LISP_UNION_TYPE the compiler will tell you,

Thanks for the hint.  Also to David.

-- 
Ralf

Re: Emacs geometry

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 25 Jul 2006 23:41:47 +0300, Eli Zaretskii <eliz@gnu.org> said:

> you should instead honor f->left_pos and f->top_pos, if they were
> set from initial-frame-alist.  The problem is to decide correctly
> when to honor them.

Maybe XSizeHints emulation on the Mac Carbon port is relevant to this.

1. `struct mac_output' (in macterm.h) has a member for size hints.

#define FRAME_SIZE_HINTS(f) ((f)->output_data.mac->size_hints)

2. `x_make_frame_visible' (in macterm.c) checks the flag in the size
   hints to see if f->left_pos and f->top_pos are set by the user.  If
   not, reposition the frame to the center of the main screen when
   there is no selected frame, and to the cascading position with
   respect to the selected frame when it is available.

      if (! FRAME_ICONIFIED_P (f)
	  && ! f->output_data.mac->asked_for_visible)
	{
#if TARGET_API_MAC_CARBON
	  if (!(FRAME_SIZE_HINTS (f)->flags & (USPosition | PPosition)))
	    {
	      struct frame *sf = SELECTED_FRAME ();
	      if (!FRAME_MAC_P (sf))
		RepositionWindow (FRAME_MAC_WINDOW (f), NULL,
				  kWindowCenterOnMainScreen);
	      else
		RepositionWindow (FRAME_MAC_WINDOW (f),
				  FRAME_MAC_WINDOW (sf),
#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1020
				  kWindowCascadeStartAtParentWindowScreen
#else
				  kWindowCascadeOnParentWindowScreen
#endif
				  );
	      x_real_positions (f, &f->left_pos, &f->top_pos);
	    }
	  else
#endif
	    x_set_offset (f, f->left_pos, f->top_pos, 0);
	}

3. `x_set_offset' (in macterm.c) enforces a constraint that the title
   bar should be visible at least partially.  We have a menu bar at
   the top of screen on Mac, so it is needed in order to prevent the
   title bar from being hidden when f->top_pos == 0.

#if TARGET_API_MAC_CARBON
  MoveWindowStructure (FRAME_MAC_WINDOW (f), f->left_pos, f->top_pos);
  /* If the title bar is completely outside the screen, adjust the
     position. */
  ConstrainWindowToScreen (FRAME_MAC_WINDOW (f), kWindowTitleBarRgn,
			   kWindowConstrainMoveRegardlessOfFit
			   | kWindowConstrainAllowPartial, NULL, NULL);
  x_real_positions (f, &f->left_pos, &f->top_pos);
#else

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs geometry

[Ralf Angeli]

* Eli Zaretskii (2006-07-25) writes:

> Here's what I saw in the code, that would perhaps help you.  When
> Emacs sees -geometry, it puts the width and height parameters into
> both default-frame-alist and initial-frame-alist, but top and left
> only into initial-frame-alist.

Okay, that matches the description of the `geometry' X resource in
(info "(emacs)Table of Resources").  The description of the --geometry
command line option, however, doesn't mention a different treatment
of initial and following frames:

,----[ (info "(emacs)Window Size X") ]
| `-g WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
| `--geometry=WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
|      Specify the size WIDTH and HEIGHT (measured in character columns
|      and lines), and positions XOFFSET and YOFFSET (measured in
|      pixels).  This applies to all frames.
`----

That's probably a documentation bug (unless the option is really
treated this way on X, which I haven't looked up).

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 25 Jul 2006 23:29:05 +0200
> 
> Okay, that matches the description of the `geometry' X resource in
> (info "(emacs)Table of Resources").  The description of the --geometry
> command line option, however, doesn't mention a different treatment
> of initial and following frames:
> 
> ,----[ (info "(emacs)Window Size X") ]
> | `-g WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
> | `--geometry=WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
> |      Specify the size WIDTH and HEIGHT (measured in character columns
> |      and lines), and positions XOFFSET and YOFFSET (measured in
> |      pixels).  This applies to all frames.
> `----
> 
> That's probably a documentation bug (unless the option is really
> treated this way on X, which I haven't looked up).

I think it's a documentation bug, since x-win.el's version of
x-handle-geometry handles these 4 parameters exactly the same way as
w32-win.el.

Re: Emacs geometry

[Eli Zaretskii]

> From: Ralf Angeli <angeli@caeruleus.net>
> Date: Tue, 25 Jul 2006 23:29:05 +0200
> 
> The description of the --geometry command line option, however,
> doesn't mention a different treatment of initial and following
> frames:
> 
> ,----[ (info "(emacs)Window Size X") ]
> | `-g WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
> | `--geometry=WIDTHxHEIGHT[{+-}XOFFSET{+-}YOFFSET]]'
> |      Specify the size WIDTH and HEIGHT (measured in character columns
> |      and lines), and positions XOFFSET and YOFFSET (measured in
> |      pixels).  This applies to all frames.
> `----
> 
> That's probably a documentation bug (unless the option is really
> treated this way on X, which I haven't looked up).

I fixed this in the manual.

Re: Emacs geometry

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 24 Jul 2006 21:15:10 -0700
> 
> With emacs -Q:
> 
> The initial frame is 2 or 3 cm from the upper left of the display (more or
> less like what happens if you do (set-frame-position (selected-frame) 100
> 100)); in the past, the initial frame has always been flush with top left.

With "emacs -Q" and without any geometry definitions in the registry,
this is now the intended behavior.  I think it's an improvement over
what was before, but that's me.

Re: Emacs geometry

[Eli Zaretskii]

> From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> Date: Mon, 24 Jul 2006 20:21:26 +0000 (UTC)
> 
> I am using the latest CVS emacs on Windows XP. It is compiled using VS 2002.
> This problem has recently started occurring. New frames in emacs are now offset
> (by about a line both horizontally and vertically) from the existing frame.
> Previously, all frames used to be offset +0+0 from the left-top corner of the
> screen (i.e no offsetting was taking place).

With "emacs -Q", this is the intended behavior: the latest changes let
the system locate the Emacs frame.  The original cause for the change
was to avoid locating the Emacs frame in the portions of the screen
occupied by the task bar and other decorations.

> My Emacs.geometry registry entry used to specify 80x48. I tried
> 80x48+0+0, but got the same behavior as before.
> 
> Is there a new setting that I need to use or is this "by design" that others are
> also encountering? If it is the latter, what is the setting that would cause all
> frames not to exhibit offsetting?

Setting the geometry in the default-frame-alist should work.  However,
you should be able to set the geometry in the registry as well.
Please provide the details--what are your settings in the registry,
when did you last resync with the CVS, and how to reproduce the
problem with "emacs -Q".

Re: Emacs geometry

[Sridhar Boovaraghavan]

On Tuesday July 25, 2006 06:26:35 +0300, Eli Zaretskii wrote:
 > > From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
 > > Date: Mon, 24 Jul 2006 20:21:26 +0000 (UTC)
 > > 
 > > I am using the latest CVS emacs on Windows XP. It is compiled using VS 2002.
 > > This problem has recently started occurring. New frames in emacs are now offset
 > > (by about a line both horizontally and vertically) from the existing frame.
 > > Previously, all frames used to be offset +0+0 from the left-top corner of the
 > > screen (i.e no offsetting was taking place).
 > 
 > With "emacs -Q", this is the intended behavior: the latest changes let
 > the system locate the Emacs frame.  The original cause for the change
 > was to avoid locating the Emacs frame in the portions of the screen
 > occupied by the task bar and other decorations.
 > 
 > > My Emacs.geometry registry entry used to specify 80x48. I tried
 > > 80x48+0+0, but got the same behavior as before.
 > > 
 > > Is there a new setting that I need to use or is this "by design" that others are
 > > also encountering? If it is the latter, what is the setting that would cause all
 > > frames not to exhibit offsetting?
 > 
 > Setting the geometry in the default-frame-alist should work.  However,
 > you should be able to set the geometry in the registry as well.
 > Please provide the details--what are your settings in the registry,
 > when did you last resync with the CVS, and how to reproduce the
 > problem with "emacs -Q".
 > 

Thanks for responding.

I updated from CVS on Sunday, did a nmake bootstrap - I should be
pretty current.

In my registry, Emacs.Geometry = 80x48+0+0 (used to be 80x48). With
this setting and emacs -Q, default-frame-alist shows width as 80 and
height as 48, but comes up with an offset to the command prompt (DOS
box). Other registry settings that I have are to set the background,
cursorcolor, foreground and mousecolor.

I also tried setting a variable called geometry in default-frame-alist
to 80x48+0+0, saved it for this session, created a new frame (C-x 5 2)
and got the same behavior as before (offset frame). Is there a
variable called geometry that can be set in default-frame-alist?

It looks to me that the +0+0 in the Emacs.Geometry is being
ignored. Is that a bug? If not, how should I specify the geometry to
achieve the behavior that I want - i.e. have all frames start from the
left-top corner.

Thanks,
Sridhar

-- 
Sridhar Boovaraghavan
sridhar_ml@yahoo.com
http://vidyasridhar.no-ip.org/

Re: Emacs geometry

[Ralf Angeli]

* Sridhar Boovaraghavan (2006-07-25) writes:

> It looks to me that the +0+0 in the Emacs.Geometry is being
> ignored. Is that a bug?

It could be called a missing feature.

> If not, how should I specify the geometry to
> achieve the behavior that I want - i.e. have all frames start from the
> left-top corner.

You can use the registry keys Emacs.Top and Emacs.Left to specify the
vertical and horizontal coordinates of the top left frame corner.
Analogously you can use `top' and `left' in `default-frame-alist'.
The former method of specifying the coordinates is favorable because
the are applied to the first frame right at its creation.

-- 
Ralf

Re: Emacs geometry

[Eli Zaretskii]

> Date: Mon, 24 Jul 2006 21:46:45 -0700
> From: Sridhar Boovaraghavan <sridhar_ml@yahoo.com>
> Cc: emacs-devel@gnu.org
> 
> In my registry, Emacs.Geometry = 80x48+0+0 (used to be 80x48). With
> this setting and emacs -Q, default-frame-alist shows width as 80 and
> height as 48, but comes up with an offset to the command prompt (DOS
> box).

It looks like there's some bug, because -geometry=80x48+0+0 doesn't
work from the command line either.  I asked Ralf Angeli to look into
this.

> I also tried setting a variable called geometry in default-frame-alist
> to 80x48+0+0, saved it for this session, created a new frame (C-x 5 2)
> and got the same behavior as before (offset frame). Is there a
> variable called geometry that can be set in default-frame-alist?

In default-frame-alist, you should set the parameters `top' and `left'
for position, and `height' and `width' for dimensions.  This does
work, I think.