Status of MAC/W32/X consolidation -- third major patch committed.

Status of MAC/W32/X consolidation -- third major patch committed.

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

I have now consolidated the common code related to frame-parameter
handling from xfns.c, w32fns.c, and macfns.c into frame.c.

Again, I have only been able to test this on X (under GNU/Linux), so
there may be some problems compiling (and running) the consolidated
code on W32 and MAC.  The MSDOS port may also be affected by this
change.  

Please report any problems to me (unless you can fix them yourself).


I do not plan to make any further consolidation of this magnitude, but
you may still expect some wide changes related to the introduction of
per-window parameters to supplement the current per-frame parameters,
and swapping of the fringe and display margin.

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

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[Andrew Choi]

storm@cua.dk (Kim F. Storm) writes:

> I have now consolidated the common code related to frame-parameter
> handling from xfns.c, w32fns.c, and macfns.c into frame.c.
> 
> Again, I have only been able to test this on X (under GNU/Linux), so
> there may be some problems compiling (and running) the consolidated
> code on W32 and MAC.  [...]

A few small changes were required to build on Mac OS X with Carbon.  I
have just checked these in.

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[Kim F. Storm]

Andrew Choi <akochoi@shaw.ca> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I have now consolidated the common code related to frame-parameter
> > handling from xfns.c, w32fns.c, and macfns.c into frame.c.
> > 
> > Again, I have only been able to test this on X (under GNU/Linux), so
> > there may be some problems compiling (and running) the consolidated
> > code on W32 and MAC.  [...]
> 
> A few small changes were required to build on Mac OS X with Carbon.  I
> have just checked these in.

Thank you.  And thanks to Juanma for fixing the W32 port.

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

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[David PONCE]

Hi Kim,

>I have now consolidated the common code related to frame-parameter
>handling from xfns.c, w32fns.c, and macfns.c into frame.c.
[...]

Thanks again for your effort!

I just noticed a minor issue, since your latest changes.

Now, while Emacs is loading my init file, the startup frame seems to
be frozen, and the echo area no more displays the messages sent during
the load process.

In fact, I just see an empty "white" frame with the title area and the
menu bar, and nothing more until the initial load process is
completed.

It is not really important, just a little baffling.  Also, I must
confess that I liked to see the progress of Emacs startup ;-)

Here is my configuration:

GNU Emacs 21.3.50.1 (i386-mingw-nt4.0.1381)
 of 2003-04-01 on EBAT311
configured using `configure --with-gcc (3.2)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Sincerely,
David

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[Kim F. Storm]

David PONCE <david.ponce@wanadoo.fr> writes:

> I just noticed a minor issue, since your latest changes.
> 
> Now, while Emacs is loading my init file, the startup frame seems to
> be frozen, and the echo area no more displays the messages sent during
> the load process.
> 
> In fact, I just see an empty "white" frame with the title area and the
> menu bar, and nothing more until the initial load process is
> completed.

Have you tried a fresh configure + make bootstrap to see if the
problem persists?

> 
> It is not really important, just a little baffling.  Also, I must
> confess that I liked to see the progress of Emacs startup ;-)

I'm sorry, but I have no way to confirm or reproduce this, so I hope
someone else can take a look at it.


> 
> Here is my configuration:
> 
> GNU Emacs 21.3.50.1 (i386-mingw-nt4.0.1381)
>  of 2003-04-01 on EBAT311
> configured using `configure --with-gcc (3.2)'
> 
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   locale-coding-system: iso-latin-1
>   default-enable-multibyte-characters: t
> 
> Sincerely,
> David
> 
> 
> 

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

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[David PONCE]

Hi Kim,

[...]
> Have you tried a fresh configure + make bootstrap to see if the
> problem persists?

I just did that and nothing changed.

[...]
> I'm sorry, but I have no way to confirm or reproduce this, so I hope
> someone else can take a look at it.

I hope too ;-)

Thanks!
David

Re: Status of MAC/W32/X consolidation -- third major patch committed.

[David PONCE]

Hi Kim,

[...]
>>I just noticed a minor issue, since your latest changes.
>>
>>Now, while Emacs is loading my init file, the startup frame seems to
>>be frozen, and the echo area no more displays the messages sent during
>>the load process.
>>
>>In fact, I just see an empty "white" frame with the title area and the
>>menu bar, and nothing more until the initial load process is
>>completed.
[...]

I finally found why I didn't saw messages displayed in the echo area
during emacs startup.  My emacs initial frame was greater than my
screen size, and the echo area was hidden!

In fact, as I work on a laptop I had setup my Emacs geometry to
"96x35+-4+-4" so that Emacs will occupy all the screen at startup.

Since your latest change, given the above geometry, I actually get an
initial frame geometry of "96x38+-4+-4".  The height is added 3,
which I suppose is the tool bar height.

I just setup the geometry to "96x32+-4+-4" to see again my echo area!

IMO, the previous behavior was better because it respected the
geometry specified by the user.

Hope this will help.

Sincerely,
David