[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-s

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.
Date: Mon, 25 Oct 2010 04:20:15 -0400

> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> From: Glenn Morris <address@hidden>
> Date: Mon, 25 Oct 2010 00:56:56 -0400
> I find it weird that when faced with the issue "we need to define a
> function, eg x-display-list, on multiple platforms; it should have the
> same arguments, doc-string, and behaviour on each platform" that Emacs
> consistently chose to have three completely separate definitions in
> three separate files; rather than just having one with #ifdefs for
> each platform where needed.
> Does anyone know what the reason for this design choice was?

It's not a conscious design choice, just a historical accident.

> Was it just that each port was developed independently by copying
> the X files and modifying them, and nobody ever merged them?

Yes.  Also because the original X-centric design never bothered to
separate the parts which are specific to X from purely Emacs
internals.  This made copy/paste job much easier than the refactoring
required for adding yet another windowing backend.

Btw, "nobody ever merged them" is not entirely true.  Over the years,
several such merges were done; as result, we now have menu.c where
previously there were only xmenu.c and w32menu.c, and also several
functions were moved from xterm.c/w32term.c to xdisp.c.  So it's more
accurate to say that the merge was never completed.

In my experience, most of the job that's left should start by defining
portable (and opaque, as far as possible) data types, and portable
wrapper functions, that will have different definitions on different
platforms.  If this is done well, the rest should be almost a
mechanical job.

> Or is/was there some advantage to this duplication?

No advantages; only disadvantages.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]