From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Improving X selection? Date: Sun, 10 Feb 2008 13:42:24 -0500 Message-ID: References: <8e24944a0802011115h77423fd1p2eae15a1e46bca1a@mail.gmail.com> <8e24944a0802011617k66c49283id9478dc3d5168bdf@mail.gmail.com> <8e24944a0802030338i1ce3397yba581ffedbe2f118@mail.gmail.com> <47A5B737.8000804@swipnet.se> <8e24944a0802030512t77c4ca20s6d059df50295ebd2@mail.gmail.com> <8e24944a0802041302n45064c4fm2ac428ceda204254@mail.gmail.com> <47A80B57.3050402@swipnet.se> <8e24944a0802061957re4baf7cr9560fa3496be56b4@mail.gmail.com> <47AACA36.9060901@gnu.org> <8e24944a0802070832l71e8fb1el91527f0b72d06a28@mail.gmail.com> <47AB3C55.4010701@gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1202669076 24533 80.91.229.12 (10 Feb 2008 18:44:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Feb 2008 18:44:36 +0000 (UTC) Cc: Tom.Horsley@ccur.com, david.delaharpe.golden@gmail.com, jan.h.d@swipnet.se, emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 10 19:44:57 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JOHAe-0001Zl-7X for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2008 19:44:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOHAB-00071Z-6I for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2008 13:44:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JOH8F-0005g0-Lh for emacs-devel@gnu.org; Sun, 10 Feb 2008 13:42:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JOH8E-0005e6-3O for emacs-devel@gnu.org; Sun, 10 Feb 2008 13:42:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOH8D-0005ds-RE for emacs-devel@gnu.org; Sun, 10 Feb 2008 13:42:25 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JOH8D-0003xl-L8 for emacs-devel@gnu.org; Sun, 10 Feb 2008 13:42:25 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1JOH8C-0007K7-Mv; Sun, 10 Feb 2008 13:42:24 -0500 In-reply-to: <47AB3C55.4010701@gnu.org> (message from Jason Rumney on Thu, 07 Feb 2008 17:13:57 +0000) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:88642 Archived-At: Something is messed up with cus-dep On my GNU/Linux build cus-load contains (put 'killing 'custom-loads '(w32-vars)) while on my Windows build, it contains (put 'killing 'custom-loads '(simple x-win)) I have some idea why it is doing this. The idea of cus-dep.el and cus-load.el is that if you want to look at the custom group `killing', you want to to load all the relevant files that are not loaded anyway. I think that on GNU/Linux it concludes you need to load `w32-vars', while on Losedows it thinks you need to load `x-win'. It puzzles me that it includes `simple', since that's preloaded and should therefore be excluded. I also don't know why `mac-win' does not get included. Nonetheless, it appears this is not a coding error, but a real problem of what to do in cus-dep with files meant only for one system. Since there are not a lot of such files, and we don't add new ones often, I think we don't need a very elegant solution. A simple quick solution is to define a variable in cus-dep.el that lists these files, and exclude them from consideration. Does anyone see a problem with this solution and want to do something fancier?