From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Omitting Windows-specific parts from infrastructure changes Date: Sun, 18 Jan 2015 21:50:04 +0200 Message-ID: <837fwjzx5f.fsf@gnu.org> References: <838uh32gpg.fsf@gnu.org> <54B9D960.1000001@cs.ucla.edu> <834mrp24b1.fsf@gnu.org> <54BBF6E7.3090802@cs.ucla.edu> <83a91gymld.fsf@gnu.org> <54BC08B2.8070302@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1421610648 25909 80.91.229.3 (18 Jan 2015 19:50:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 19:50:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 18 20:50:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YCvs0-0003Kk-4x for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 20:50:48 +0100 Original-Received: from localhost ([::1]:34530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCvrz-00019i-Nx for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 14:50:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCvrc-00019F-Ib for emacs-devel@gnu.org; Sun, 18 Jan 2015 14:50:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCvrY-0007XQ-GW for emacs-devel@gnu.org; Sun, 18 Jan 2015 14:50:24 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:64036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCvrY-0007X9-8H for emacs-devel@gnu.org; Sun, 18 Jan 2015 14:50:20 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NIE00I001NBCG00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sun, 18 Jan 2015 21:50:17 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIE00IEX1RS5Z80@a-mtaout21.012.net.il>; Sun, 18 Jan 2015 21:50:16 +0200 (IST) In-reply-to: <54BC08B2.8070302@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181412 Archived-At: > Date: Sun, 18 Jan 2015 11:25:38 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > >>> I'm sure when you do such changes, you > >>> grep (or otherwise search) the whole tree for relevant places > >> > >> No, I hardly ever do that. > > > > Then please start doing that from now on. > > I'd rather not. If someone else wants to search other modules for opportunities > to make similar changes, that's obviously fine, but's it's not at all necessary. > Work like this should belong to the modules in question; among other things, > it is more efficiently done by people who care about and are expert in those > modules. But I didn't ask you to do the actual work, just point out the files where changes similar to what you did might be needed. That's all. Without that, people who do want to do the work are basically unable to do it, without repeating what you already did anyway, and on top of that they need to guess what methods you used to identify the places where changes are needed -- something that isn't documented in the change logs. IOW, basically the request is to post a short note about things you know anyway. The only extra work is composing the message itself. > >> Ideally, the MS-Windows code would be a completely separate module > > > > That's a completely separate issue, unrelated to the issue at hand. > > No, the issues are related. If the modules in question were completely > independent, this thread would not have come up. It would have come up anyway, since the same infrastructure is used everywhere. It's the same C language, the same object system, the same Makefile's and build system, etc.