Re: Removing the usage of X structures (or their names) in independent code

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 09 May 2019 10:26:44 -0600
> 
> > Why do you prefer a union?  It uglifies the code and makes it harder
> > to read and understand.  OTOH, having a backend-independent type (what
> > you call "typedef") is much cleaner.
> 
> The union approach would be more future-proof (if the goal of multiple
> backends at once is realized), and I find it neater than having
> different types per backend. I would consider the union approach as
> having a "backend-independent type"; in the union approach, all backends
> of Emacs would have that union as the type, whereas in the typedef
> approach each backend pastes its own type into the generic parts of the
> code.
> 
> The above goal is still far away, so it wouldn't be terrible to use
> typedefs in the interim.

Yes, I'd prefer not to make changes that are needed by future far-away
goals, especially when those changes makes the code less readable.

> > If that new structure is defined as (for example)
> >
> >   typedef XColor EColor;
> >
> > then there's no overhead at all: you could simply assign an EColor to
> > XColor or even use the former directly in APIs that want the latter.
> 
> Right, I meant overhead in the case of defining a new structure rather
> than defining a new name for the structure. For example:
> 
> struct EColor
> {
>   uint16_t red;
>   uint16_t blue;
>   uint16_t green;
>   uint16_t alpha; /* Who knows, maybe? */
>   unsigned long long pixel;
> };
> 
> Which would need to be converted to XColor on the X backend.

But that's not needed if you use typedef as above for X.  And for
non-X platforms we already have a definition of XColor, which just
needs to be renamed to EColor.

> > For more complex situations, see what we do with 'struct font' and
> > 'struct FOOfont' for font backend FOO.
> 
> Could you point me to somewhere specific for this? I'm unsure to what
> you're referring.

For example, in ftfont.h:

struct font_info
{
  struct font font;
#ifdef HAVE_LIBOTF
  bool maybe_otf;	/* Flag to tell if this may be OTF or not.  */
  OTF *otf;
#endif	/* HAVE_LIBOTF */
  FT_Size ft_size;
  int index;
  [...]
}

And an example how this is used in xftfont.c:

static int
xftfont_draw (struct glyph_string *s, int from, int to, int x, int y,
              bool with_background)
{
  block_input ();

  struct frame *f = s->f;
  struct face *face = s->face;
  struct font_info *xftfont_info = (struct font_info *) s->font;

This is for when you need to extend a platform-independent struct (in
this case 'struct font') with platform-dependent additions.

> In any case, would you prefer using names like EColor, EPixmap, EGC, or
> Emacs_Color, Emacs_Pixmap, Emacs_GC?

The Emacs_ prefix is short enough, so I guess it's better.