emacs-devel
[Top][All Lists]
Advanced

[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 05:28:28 -0400

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Stefan Monnier <address@hidden>,
>     Eli Zaretskii <address@hidden>,
>     address@hidden
> Date: Mon, 25 Oct 2010 17:03:40 +0900
> 
> It's true that for very similar display types such as Xt and GTK+
> where much of the code can be reused[1], it may make sense to create a
> single file with the common code, and include it multiple times with
> preprocessor tweaking to make the names fit and to register driver
> functions in the right tables.  But there's no point in this for X
> drivers vs. MS Windows drivers; they're going to have very little
> common code.

Actually, the common code is quite abundant, because the back-end
specific code is not well separated from the platform independent code
that manipulates Emacs internal objects.  This causes maintenance
headaches, whereby work on the same bug or feature needs to be done in
several places.

E.g., I recently discovered that various bugfixes and new features
introduced into mouse highlight were done only in the GUI parts of the
display engine, even though the TTY display also supports mouse
highlight (with GPM).  This was because the TTY code used a slightly
tailored version of a function that was originally written for in
xterm.c.  Then the GUI variant of that function was developed, while
the TTY variant was simply forgotten in its original shape.

So keeping the common code common makes sense even if Emacs will never
be used on X and MS-Windows in the same session, and even if the
back-ends are very different.



reply via email to

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