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

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

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 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

Status of MAC/W32/X consolidation and some questions.

[Kim F. Storm]

[There are a couple of MAC and W32 specific questions in this mail.
Those who know these ports well, please take a look at them.]


As you may have seen on emacs-devel, I'm in the process of
consolidating the various ports of CVS emacs for X, W32, and MAC.

Most of this work is to identify (and merge) code which basically only
differs in "names" rather than "structure", e.g. by using FRAME_X_P in
the X version, and FRAME_MAC_P in the MAC version, but otherwise is
identical.

AFAICS, the best option for maximum code sharing is to extend the
current approach in the MAC and W32 ports of using part of the X port
name space, e.g. by defining a partial x_output structure to satisfy
the needs of the basic code which expects an x_output structure to
exist, or by defining some of the FRAME_X_* macros to point to the
output_data.mac structure.

Now, what I'm currently working on is to replace all mac* and w32*
specific names with the corresponding x* names, e.g. FRAME_MAC_WINDOW
is replaced by FRAME_X_WINDOW, mac_output is replaced by x_output,
f->output_data.mac becomes f->output_data.x, etc. etc.

As I progress in this regard, the amount of code which can then be
shared directly between the ports gets larger and larger.

One major drawback of this approach is that while the current
"overloading of the X* specific names makes it difficult to make a
version which supports both MAC and X simultaneously (i.e. in the same
executable), extending this "overloading" to cover all the MAC and W32
specific code makes it practically impossible to support such
cross-GUI systems that later on.

However, I got the message from RMS, that this limitation was
acceptable (and I agree), so I'm doing just that, as it gives the
maximum benefits with the least amount of work (still it *is* a lot of
tedious work :-)

However, one of the "merged" macros is giving me problems: FRAME_MAC_P
and FRAME_W32_P cannot simply be merged into FRAME_X_P (for various
reasons), but I'll find a way :-)


On W32, FRAME_W32_P seems to be true even when HAVE_NTGUI is not
defined (at lease Fframe_parameter in frame.c seems to assume this),
so while FRAME_X_P and FRAME_MAC_P means that the output is to a
GUI, FRAME_W32_P only means that output is to a w32 system as such.

So my questions to the W32 experts are: 

* Does it make sense to build NTemacs without HAVE_NTGUI defined?
  Is it possible to do that?

* Does the W32 version support -nw?
  If so, is FRAME_W32_P still true when specified?


On MAC, I noticed two places in macterm.c where FRAME_X_P is tested
rather than FRAME_MAC_P, which basically means that the corresponding
code _IS_NOT_ executed:

 * In x_flush, the call to XFlush is conditioned by FRAME_X_P

 * In XTframe_up_to_date, the entire code is conditioned by FRAME_X_P.

Could a MAC expect please check these two strange-looking cases for
me, thanks!

Also on MAC, there are quite a number of TODO items, meaning that some
section of more-or-less unmodified X or W32 code is commented out with
#if 0...  #endif.  In the cases where the code is to be "consolidated",
I would prefer to leave a TODO note in the mac* file and simply delete
the code from the file.  Then in the consolidated code file, I will
put a #ifndef MAC_OS around the consolidated code to indicate that it
is not used on MAC_OS (yet).   Is that an acceptable approach?



Since I'm working on this right now, I would advise everyone to commit
any major changes that you may have in your local checkout, as
the structure of the code is going to change quite a lot due to
my work (the consolidated code is going to be moved out of the
mac* specific files).

Also, since I cannot really test the changes on MAC and W32, I do
expect that I'm going to make a few mistakes in the consolidation,
resulting in non-functional MAC and W32 versions on the CVS head,
which I hope some of you will assist me in solving (I hope/expect it
is just a matter of fixing some trivial compilation errors).


-- 
Kim F. Storm  http://www.cua.dk

Re: Status of MAC/W32/X consolidation and some questions.

[Kim F. Storm]

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

> As you may have seen on emacs-devel, I'm in the process of
> consolidating the various ports of CVS emacs for X, W32, and MAC.

.. which turns out to be a bigger task than I first imagined.  Sigh!

> 
> Most of this work is to identify (and merge) code which basically only
> differs in "names" rather than "structure", e.g. by using FRAME_X_P in
> the X version, and FRAME_MAC_P in the MAC version, but otherwise is
> identical.
> 
> AFAICS, the best option for maximum code sharing is to extend the
> current approach in the MAC and W32 ports of using part of the X port
> name space, e.g. by defining a partial x_output structure to satisfy
> the needs of the basic code which expects an x_output structure to
> exist, or by defining some of the FRAME_X_* macros to point to the
> output_data.mac structure.

I'm getting less enthustiastic about this approach as a general way
to achieve the goal of reducing duplicate code (but it will still
be useful in many places).  

Although this method does allow sharing of more code (taken from the
xfns.c and xterm.c files), it makes a pretty arbitrary split between
the parts of xfns.c and xterm.c which are "shareable" and those parts
which are not.

Consequently, if I take out the parts of xfns.c and xterm.c which are
shareable and place them in, say, genfns.c and genterm.c, it really
makes a hotch-potch output of those four files, probably making the X
version harder to maintain -- simply because the code is broken apart
into what may seem pretty arbitrarty files (that's already the case
for some of the code, but it's probably getting even worse with this
approach).


A different approach - which I think I like better - is to try to
generalize some things rather than overloading names, e.g.

* move common parts of x_output, w32_output, and mac_output directly
  into the frame structure.  Then code doesn't have to go through the
  correct output_data macro, but can get to the data directly from the
  frame pointer.  This adds some overhead to the frame structure for
  non-windowing frames, but it's a VERY SMALL price to pay for
  increased portability.

* generalize code sections by extending the redisplay_interface so
  that common code can be moved out of e.g. xterm.c, but still have
  hooks into xterm.c to do the things that are really X specific.
  A good example is the handling of fringes.

* export more of the window system specific low-level
  functions like clipping and filling through the redisplay_interface.

* maybe generalize the glyph processing along the same lines.


The biggest advantage of this approach is that is can be done in
smaller steps, rather than the planned "change everything in one
big step" approach.  

So probably you should be prepared for a number of smaller, more
focused consolidation updates, rather than a single BIG one...


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

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

[Kim F. Storm]

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

> As you may have seen on emacs-devel, I'm in the process of
> consolidating the various ports of CVS emacs for X, W32, and MAC.

I have just committed a fairly big set of changes primarily to
xdisp.c, xterm.c, w32term.c, and macterm.c to consolidate the
gui-independent parts of the "glyph string" processing.

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.  Please report any problems to me (unless you can fix
them yourself).

More consolidation patches will following in the coming days/weeks.

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

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

[Kim F. Storm]

> storm@cua.dk (Kim F. Storm) writes:
> 
> > As you may have seen on emacs-devel, I'm in the process of
> > consolidating the various ports of CVS emacs for X, W32, and MAC.
> 
> More consolidation patches will following in the coming days/weeks.

As "promised", I have just committed another major patch to
consolidate the remaining duplicate code from xterm.c, w32term.c and
macterm.c into xdisp.c.  

So far, a total of 15000 lines of code from those three files have
been merged into just 5000 lines in xdisp.c.  There are still a few
minor thunks of duplicate code left, but IMO it's not worth the
efforts to squeeze those files any further.

My next step is to consolidate the duplicate code from xfns.c,
w32fns.c and macfns.c.

The ChangeLog has this blurb about the second major patch:

	The following changes consolidate code related to writing and
	inserting glyphs, exposing frame, the tool bar, the mouse face,
	the output cursor, and help echo from xterm.c, w32term.c and
	macterm.c into xdisp.c.  It also generalizes the use of the
	window_part enum instead of using numeric values throughout.

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


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

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