emacs-devel
[Top][All Lists]
Advanced

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

Re: Is it possible to have 256 colors in Emacs on framebuffer-enabled tt


From: zwz
Subject: Re: Is it possible to have 256 colors in Emacs on framebuffer-enabled tty
Date: Tue, 30 Aug 2011 22:05:50 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

David De La Harpe Golden <address@hidden> writes:

> On 29/08/11 10:06, zwz wrote:
>
>> I made some mistake. The problem "tput color -> 256; Emacs -> 256 but
> in
>> fact 8" only happens when I set TERM=xterm-256color, which is not the
>> case since I am actually using fbterm.
>
> That was unlikely to work anyway, as the fbterm guys have apparenrtly
> chosen to use quite different escapes to xterm for 256 colors.  I
> understand that they were seeking to retain compat with linux kernel vt,
> and the linux vt was already using that escape (for something fairly
> unimportant IIRC*), but since they are _not_ the linux vts and they
> _are_ a different terminal anyway, IMO they would have been better off
> using the same escapes as xterm (and everyone else) for 256 colors and
> just moving the linux vt one somewhere, but anyway. At the same time,
> they're probably "in the right" insofar as apps properly using terminfo
> should be able to cope with both.
>
> Emacs probably should be querying more from terminfo and hardcoding less
> (yeah yeah, "patches welcome", I know).  In any case, right now, we
> probably do need a lisp/term/fbterm.el, and unfortunately it probably
> can't completely reuse the xterm.el code, unlike screen.el

Do you mean if there is a lisp/term/fbterm.el that deals with the
escapes, then it is possible to have 256 colors in Emacs on fbterm?

>
> * I remember looking at feasibility of a linux kernel patch for native
> 256-color vts on framebuffers years ago but my attention rapidly
> wandered...

This seems to be a better solution.




reply via email to

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