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

[Kim F. Storm]

address@hidden (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 <address@hidden> http://www.cua.dk