Be prepared for "code clean-up" in CVS head

[Kim F. Storm]

I've finally found some time to look into two of my to-do
list items:

1) making the fringes configurable on a per-window basis, rather than
just on a per-frame basis.

2) moving the fringe from "outside display margin" to "between
display margin and text area".

While working on item 1), I'm looking into making the scroll-bar
configurable on a per-window basis too (that is pretty much already
working for me here under X).  As an added bonus (and proof of
concept), I plan to make a new "auto-show-scroll-bars" mode which will
make the scroll bar visible only when the window needs it.

Now, since I can foresee that I need to make many practically
identical changes to the X, W32 and MAC ports, I think it is about
time that some of the (extensive) code-duplication between the X, W32,
and MAC ports is cleaned up.

We discussed this some time ago, and it was put on hold, as it was
envisioned that the GTK toolkit efforts would somehow obsolete that
work.  Since GTK support is now installed -- but as an X-specific
option -- the original task still remains.

I don't intend to make a lot of changes to identify and merge
duplicate code, but I will at least merge the code and definitions
that are related to the changes I'm going to make to facilitate the
"fringe/margin swap" and the per-window configurations.

As far as I can see, most of the changes will be related to the *term.c,
*term.h, *fns.c, and frame.h files.

For merged code, I plan to move it into frame.c or xdisp.c, but I may
decide to add comfns.c and comterm.c files and move some code into those
if the amount of common code is significant.


On a closely related matter, it seems that some corners of the code
_could_ work with multiple GUI output devices, e.g. W32 and X, but
many parts of the code definitely does not support that, particularly
much of the code ported to W32 and MAC uses the X-specific names of
both functions and #defines, and they also defines structs and types
to match the X-specific names...  So it is hard for me to see how
they can co-exist without a really MAJOR cleanup.

If we decide that we DO NOT want to support such cross-GUI hybrids, a
lot more of the duplicate code could be cleaned up.

I don't really care whether such cross-GUI hybrids is possible, but I
do care about making emacs easier to maintain -- and the current code
duplication is a major hazzle in that respect.  So if we decide not to
support the cross-GUI hybrids, I think I can cleanup a good deal more
of (almost) duplicated code.

WDYT?