Re: Merging x*, w32* and mac* sources (was Re: table.el)

[Kim F. Storm]

Eli Zaretskii <address@hidden> writes:
> 
> It's possible to make this even simpler: keep the x*.c files, and make 
> w32*.c and mac*.c serve as emulations of the X* functions called from 
> x*.c.  The person who does the actual work will have to decide which way 
> is better; the advantages and disadvantages of each one of them are 
> obvious, I think, but the actual balance needs careful evaluation.

I don't see why we cannot combine all of these methods to achieve as much
code sharing as possible (and desireable).

1) Try to emulate X* functions directly whenever that is possible,

2) put a small wrapper around the X* functions (e.g. supplying additional
   arguments) if that makes it possible to emulate the "wrapped" function, 

3a) for larger functions, find common and non-common sub-functions and
   make it easy to write emulations for the non-common parts, e.g.
   (supposing we use the x* files as the base version, whereas the w32 and
    mac files supply stub functions):

        x_some_func(f, g)
        {
                // common code
                ...

                // non-common code
        #ifndef HAVE_X_WINDOWS
                stub_some_func(f, ...)
        #else
                // the X-version of the code is here
        #endif

                // more common code
                ...
        }

3b) or if we separate the functions into com* and x/w32/mac files:
   (where the x files will also supply the stub function):

        x_some_func(f, g)
        {
                // common code
                ...

                // non-common code
                stub_some_func(f, ...)

                // more common code
                ...
        }


4) use separate functions as is currently done

Although 3b looks like a cleaner API, I prefer 3a, since that keeps
the complete function (the X-version) to look at and maintain.

I think the balance between 3 and 4 should be that 3 is used if the
non-common code is `trivial' or `small' compared to the common code,
and the non-common code can be handled in a single stub function.

Otherwise, the three different versions of the function will probably
be just as easy (or easier) to maintain as completely separate functions.


If we agree on this, it could be done gradually!

BTW, I noticed that the w32_output structure has a small (almost
dummy) x_output structure at the start to allow a few generic
occurrences of f->output_data.x->...  to work on the w32 platform.  I
think that a first step towards code sharing would be to move the
common x/w32/mac parameters from the w32_output and mac_output
structures into that (no longer dummy) x_output structure, and change
the code accordingly (output_data.w32  =>  output_data.x).

Actually, it could probably just be the normal x_output structure
with the last part conditioned by HAVE_X_WINDOWS.