From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: VMS support Date: Thu, 24 Jul 2008 15:58:09 -0400 Message-ID: References: <87iquzmcxm.fsf@stupidchicken.com> <87d4l76ntu.fsf@ambire.localdomain> <8763qznhfd.fsf@stupidchicken.com> <87k5fcc2ui.fsf@ambire.localdomain> <873alz681f.fsf@ambire.localdomain> <200807241655.m6OGtiqp008494@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216929515 2224 80.91.229.12 (24 Jul 2008 19:58:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2008 19:58:35 +0000 (UTC) Cc: Thien-Thi Nguyen , emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 24 21:59:24 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 1KM6y3-0000iX-9e for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 21:59:15 +0200 Original-Received: from localhost ([127.0.0.1]:55244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM6x9-0002KC-Rg for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 15:58:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KM6x5-0002J5-2w for emacs-devel@gnu.org; Thu, 24 Jul 2008 15:58:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KM6x2-0002Ic-OU for emacs-devel@gnu.org; Thu, 24 Jul 2008 15:58:14 -0400 Original-Received: from [199.232.76.173] (port=53315 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM6x2-0002IZ-K0 for emacs-devel@gnu.org; Thu, 24 Jul 2008 15:58:12 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:55621) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KM6x2-0001Eg-7g for emacs-devel@gnu.org; Thu, 24 Jul 2008 15:58:12 -0400 Original-Received: from alfajor.home (vpn-132-204-232-35.acd.umontreal.ca [132.204.232.35]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m6OJwAe2017014; Thu, 24 Jul 2008 15:58:11 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 770391C523; Thu, 24 Jul 2008 15:58:10 -0400 (EDT) In-Reply-To: <200807241655.m6OGtiqp008494@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Thu, 24 Jul 2008 09:55:44 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3067=0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:101415 Archived-At: >> OK, so we should get rid of the VMS code in one clean commit with a CVS >> tag before and another after. I think it's important for this commit to >> be as clean as possible (i.e. it really removes all the VMS related >> code and text), so that there won't be some future changes that remove >> a bit more of the VMS support: this way the CVS tags will faithfully >> include all the relevant code (and text). > IMO doing it this way is too high of a burden and hence not very > feasible. It pretty much forces this to be a one person job instead > of allowing it to be distributed. There are 397 references just to > the VMS string just in the C code + docs. And there are probably many > things that are only valid for VMS, but are not explicitly mentioning > the VMS string. Well, there's doing a perfect jog and then there's doing a thorough job. A perfect job is probably impossible. But handling the 397 references to vms in the C code shouldn't be that hard, and dealing with the rest of the references in the Lisp code and in the manual shouldn't be that hard either. Sure, you're going to miss some implicit references, but that's OK. If you don't want to do it, then don't do it. >> I guess we should do the same for the Carbon port since it also seems >> that nobody is interested in updating&maintaining it. > Is this a go ahead? Yes, but with the same requirement of a clean removal. Stefan