From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: display question: should ^N and \NNN widths be fixed? Date: Fri, 24 May 2002 19:39:44 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200205242114.g4OLE2T02822@aztec.santafe.edu> <87661d57dm.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1022294740 23559 127.0.0.1 (25 May 2002 02:45:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 25 May 2002 02:45:40 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17BRYq-00067s-00 for ; Sat, 25 May 2002 04:45:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17BRp0-0003P9-00 for ; Sat, 25 May 2002 05:02:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17BRYU-00067W-00; Fri, 24 May 2002 22:45:18 -0400 Original-Received: from ca-crlsbd-u5-c4a-a-172.crlsca.adelphia.net ([24.48.214.172] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17BRWy-0005kf-00; Fri, 24 May 2002 22:43:44 -0400 Original-Received: from ttn by giblet with local (Exim 3.35 #1 (Debian)) id 17BRT6-0007n3-00; Fri, 24 May 2002 19:39:44 -0700 Original-To: miles@gnu.org In-Reply-To: <87661d57dm.fsf@tc-1-100.kawasaki.gol.ne.jp> (message from Miles Bader on 25 May 2002 10:44:05 +0900) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4368 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4368 From: Miles Bader Date: 25 May 2002 10:44:05 +0900 What is an `iso-type contour'? this is a term i pulled out the air (perhaps better expressed as "functional iso-contour"? -- the math heads can jump in here) to describe a method for identifying what is it that stays the same and what changes, when using an incremental approach. iso-contours on "relief" maps typically keep the altitutde the same while varying the location. here, we want to keep the functionality the same (not break anything) while varying the type. this allows us to consider adding functionality as an independent task (so that people who are more comfortable designing/modifying those next-higher-level algorithms can take a whack at it instead of me :-). adding functionality can also be done incrementally, in the tradition of emacs development. perhaps someone can supply better terminology or metaphor... does this make sense? In general, it's better to make changes in smaller incremental steps that can be merged into main-line CVS. You already seem to be thinking that way. yes, lacking a test suite (which is perhaps untenable for emacs), small incremental approach is a necessity. so, i'll post uuencoded diffs for review, initially, to get feedback and thumbs up from rms. in the meantime, i hope to find answers to the other logistical questions. this command: cvs co -d emacs-CVSROOT CVSROOT reveals emacs-CVSROOT/modules has nothing in it. anyone mind if i create a cvs module "notes" (sibling to cvs module "emacs")? absent other better places, i would use this to keep notes, detailed TODO (for this particular initiative), etc. thi