From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Samuel Bronson Newsgroups: gmane.emacs.devel Subject: Re: eterm-color not in ncurses/terminfo (and name clash with eterm.org) Date: Mon, 4 May 2009 15:27:06 -0400 Message-ID: References: <18942.51042.70991.953283@a1ihome1.kph.uni-mainz.de> <200905041612.n44GCuFM023842@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1241466236 24377 80.91.229.12 (4 May 2009 19:43:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 May 2009 19:43:56 +0000 (UTC) Cc: Ulrich Mueller , emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 04 21:43:40 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 1M144g-0000Uk-3J for ged-emacs-devel@m.gmane.org; Mon, 04 May 2009 21:43:38 +0200 Original-Received: from localhost ([127.0.0.1]:57224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M144f-0006X7-Ks for ged-emacs-devel@m.gmane.org; Mon, 04 May 2009 15:43:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M13on-0007fD-MY for emacs-devel@gnu.org; Mon, 04 May 2009 15:27:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M13oi-0007cI-8B for emacs-devel@gnu.org; Mon, 04 May 2009 15:27:12 -0400 Original-Received: from [199.232.76.173] (port=47248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M13oi-0007cD-3Z for emacs-devel@gnu.org; Mon, 04 May 2009 15:27:08 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.171]:26594) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M13oh-0001KH-JW for emacs-devel@gnu.org; Mon, 04 May 2009 15:27:07 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 23so3038951wfg.24 for ; Mon, 04 May 2009 12:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RME8qu2tzwTgxTrR6J8WXJJKKXgze8sXyhMCdCvaI30=; b=tTvIDostF5C88cOUKV556svbZA3V/5O7aPZNH0HIcBezEGTHvR9M6QM1ZNfbmCqBq4 QP/lAz+Zmo3molRVG3Gxg6h4WSIr6fYJVZyGBLqmEC+Knq83PcugsGVNNxII38yaIXZH R6w4dFP1yjl4D/q/yGR1xrynpYM+eNc4/T/tU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=knbC+3HEW+AIFVHzF5mHN94A5UgoB5hHbx64/2yAxBZVHo3eMTEWPKJYqhkogr8at8 EMcrBsIj3IEZWjPsTszrNstIqX1JaWiHewxOPflgV7b672H1zHtIJLvIggUp/MEoRQg+ RHIjmHil+eXwWWOrXxKDCg90qnkRgqWtKyBNQ= Original-Received: by 10.142.110.10 with SMTP id i10mr2286515wfc.300.1241465226677; Mon, 04 May 2009 12:27:06 -0700 (PDT) In-Reply-To: <200905041612.n44GCuFM023842@godzilla.ics.uci.edu> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:110647 Archived-At: On Mon, May 4, 2009 at 12:12 PM, Dan Nicolaescu wrote: > Ulrich Mueller writes: > > =C2=A0> The terminal emulator of Emacs 22.3, and current CVS version too, > =C2=A0> identifies itself as "eterm-color". However, the terminfo databas= e > =C2=A0> (as included with ncurses-5.7) doesn't know about it. It has only= the > =C2=A0> following entry: > =C2=A0> > =C2=A0> ,---- > =C2=A0> | # The codes supported by the term.el terminal emulation in GNU = Emacs 19.30 > =C2=A0> | eterm|gnu emacs term.el terminal emulation, > =C2=A0> `---- > =C2=A0> > =C2=A0> Is there any reason why terminfo shouldn't know about eterm-color= ? > =C2=A0> Otherwise, I could ask the ncurses maintainers to include the ent= ry. > > When term.el starts, it sets up both TERMCAP and TERMINFO, so > applications should work just fine without any support in the standard > terminfo distribution. Hmm. I don't see any mention of TERMINFO in term.el except for the code that actually sets it ... it should be documented. Regardless: How does that work over SSH? (I do wish they had thought this sort of thing out better when they designed terminfo in the first place, but I think it's a bit late for that now...) The best thing to do with new features that are really compelling (like color!) but require incompatible additions to terminfo is probably to add another dashed suffix -- which would enable systems without the new terminfo entry to fall back to the old one -- and also to provide the necessary terminfo sources to users so they can compile the terminfo entry themselves if their local terminfo databases haven't got the new entry yet. (Too bad there isn't a better fallback mechanism...) If incompatible additions are not needed -- that is, if it doesn't pose a problem for the new terminfo entry to be used with the old term.el -- then you should just update the existing entry and, again, provide the source to users as well as to the folks at invisible-island. If the new features aren't all that compelling (few are as compelling as color), but still require incompatible changes to the terminfo in order for non-termcap applications to know about and use them, then probably the thing to do is write a new entry and allow the user to pick whether to use a TERM that requests the new feature or not. I really do almost wish the whole terminfo entry could just be stuck in the environment variable, except I'm not sure I trust terminal authors to never make mistakes in writing them ...