From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Omitting Windows-specific parts from infrastructure changes Date: Sun, 18 Jan 2015 10:09:43 -0800 Organization: UCLA Computer Science Department Message-ID: <54BBF6E7.3090802@cs.ucla.edu> References: <838uh32gpg.fsf@gnu.org> <54B9D960.1000001@cs.ucla.edu> <834mrp24b1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421604610 29812 80.91.229.3 (18 Jan 2015 18:10:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 18:10:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 18 19:10:05 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 1YCuIX-0004cd-Ci for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 19:10:05 +0100 Original-Received: from localhost ([::1]:34253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCuIW-0003m6-Aw for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 13:10:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCuIK-0003m0-DH for emacs-devel@gnu.org; Sun, 18 Jan 2015 13:09:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCuIJ-00042o-BA for emacs-devel@gnu.org; Sun, 18 Jan 2015 13:09:52 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:45025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCuID-000417-Rh; Sun, 18 Jan 2015 13:09:45 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 73602A6000F; Sun, 18 Jan 2015 10:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN1TxO4nZ97u; Sun, 18 Jan 2015 10:09:44 -0800 (PST) Original-Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 21C28A6000D; Sun, 18 Jan 2015 10:09:44 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <834mrp24b1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:181405 Archived-At: Eli Zaretskii wrote: > 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. For example, I don't look at the Lisp code if I'm changing some aspect of the C code that shouldn't affect Lisp. And in instances like the strcpy/stpcpy change, where the changes' effects don't bleed into the MS-Windows port, I don't look at the MS-Windows code. In this sense the MS-Windows code is like the OS X code, or like any other part of the Emacs source code for that matter. Ideally, the MS-Windows code would be a completely separate module, so that changes in the Emacs core would not affect it and non-MS-Windows developers would never need to worry about it. We're obviously not there, as we have too many dependencies between the core and the MS-Windows code, one of the symptoms of which is too many "#ifdef WINDOWSNT" directives sprinkled throught the core modules. In some aspects, though, we do have good separation, and this kind of separation should be encouraged, and it's good when developers can take advantage of it.