emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eterm-color not in ncurses/terminfo (and name clash with eterm.org)


From: Samuel Bronson
Subject: Re: eterm-color not in ncurses/terminfo (and name clash with eterm.org)
Date: Mon, 4 May 2009 15:27:06 -0400

On Mon, May 4, 2009 at 12:12 PM, Dan Nicolaescu <address@hidden> wrote:
> Ulrich Mueller <address@hidden> writes:
>
>  > The terminal emulator of Emacs 22.3, and current CVS version too,
>  > identifies itself as "eterm-color". However, the terminfo database
>  > (as included with ncurses-5.7) doesn't know about it. It has only the
>  > following entry:
>  >
>  > ,----
>  > | # The codes supported by the term.el terminal emulation in GNU Emacs 
> 19.30
>  > | eterm|gnu emacs term.el terminal emulation,
>  > `----
>  >
>  > Is there any reason why terminfo shouldn't know about eterm-color?
>  > Otherwise, I could ask the ncurses maintainers to include the entry.
>
> 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 ...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]