From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.sources Subject: Re: nterm a vt100 emulator Date: Mon, 19 Oct 2009 22:10:57 -0400 Message-ID: References: <87d44osokv.fsf@kanis.fr> <87skdjrgqb.fsf@kanis.fr> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256004681 7879 80.91.229.12 (20 Oct 2009 02:11:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2009 02:11:21 +0000 (UTC) Cc: Emacs Sources , emacs devel To: Ivan Kanis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 04:11:14 2009 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 1N04Bt-0007AK-O9 for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2009 04:11:13 +0200 Original-Received: from localhost ([127.0.0.1]:48084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N04Bt-0000pX-0f for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 22:11:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N04Bi-0000je-I4 for emacs-devel@gnu.org; Mon, 19 Oct 2009 22:11:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N04Bf-0000iE-3F for emacs-devel@gnu.org; Mon, 19 Oct 2009 22:11:02 -0400 Original-Received: from [199.232.76.173] (port=46742 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N04Be-0000iA-PK; Mon, 19 Oct 2009 22:10:58 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:56325 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N04Be-0002z8-Gp; Mon, 19 Oct 2009 22:10:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAE+53EpLd/m0/2dsb2JhbACBUtgMhDEEiAU X-IronPort-AV: E=Sophos;i="4.44,588,1249272000"; d="scan'208";a="47846853" Original-Received: from 75-119-249-180.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 19 Oct 2009 22:10:58 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 76A4980E7; Mon, 19 Oct 2009 22:10:57 -0400 (EDT) In-Reply-To: <87skdjrgqb.fsf@kanis.fr> (Ivan Kanis's message of "Fri, 16 Oct 2009 08:32:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:116265 gmane.emacs.sources:3307 Archived-At: >> Could you expand a bit on it? Mostly, how does it compare to term.el >> and terminal.el? > Hi Stefan, > I wrote it because I couldn't fix the cursor bug in term. That was my guess as well ;-) > term and terminal are not meant to be full emulation. term has > a pager and line mode which nterm doesn't do. nterm doesn't track > current directory like term does. That makes it sound like nterm is like term but with less features. I'm sure there's an upside to it. Also, if you could explain how these different design decisions affect the ability to fix the original cursor bug, that would be great. > I can't comment on terminal, I haven't used it. Neither have I. Has someone used it? Should we move it to `lisp/obsolete'? > Things that remains to do: > - Double width character > - Double height character > - Sanitize keyboard map > - ANSI color > - VT52 compatibility mode Does it adapt to a window's size or does it have a fixed size independent from the window where the buffer is displayed? > I think nterm is easier to maintain than term. One look at term's > term-emulate-terminal function should convince anyone that term cannot > be maintained anymore. Compare with nterm equivalent function > nterm-emulate it is only 25 lines long. term.el's maintainability is indeed a problem. Stefan