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