Using Emacs in fbterm.

Using Emacs in fbterm.

[Alan Mackenzie]

Hello, Emacs.

I think it's time to begin a new thread on fbterm, which isn't about
undisplayable characters any more.

Just as a matter of interest, I've amended my copy of the fbterm's
source code so as to remove most of the "stolen" key combinations,
leaving just S-<prior> and S-<next> in place.  These scroll the screen
vertically, allowing one to view previous messages or commands.

fbterm is hosted at GitHub, where there seem to be 28 forks of it, most
of them, probably, being very slight differences from their forkees (is
that a word?).  So much for free software.  ;-)

In the GNU/Linux distribution I use, Gentoo, the version of fbterm is
one of those forks.  One change in it, made 7 years ago, was changing
the setting of the environment variable TERM from "linux" to "fbterm".
It seems that this will vary randomly between these forks, and also
randomly between G/L distributions.  There might be something in the
terminfo setup to enable one to distinguish fbterm from the Linux
console when TERM is "linux".

There is a problem with colours in Emacs in fbterm.  When one does M-:
(defined-colors) it prints a list of just eight colours, black, red,
...., white.

However, the face constructing mechanism seems to assume more than eight
colours, and this seems buggy.  The face hi-green, for example, rather
than having background "green" gets "light green".  This appears on the
terminal as dark yellow, which is clearly wrong.

Also the face mode-line-inactive is indistinguishable from the default
face, so when there're more than one window in the frame, they are less
easy to distinguish than they should be.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 16:41:00 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> There is a problem with colours in Emacs in fbterm.  When one does M-:
> (defined-colors) it prints a list of just eight colours, black, red,
> ...., white.
> 
> However, the face constructing mechanism seems to assume more than eight
> colours, and this seems buggy.

Face constructing makes no such assumptions.  If the colors defined
for the face are not directly supported by the terminal (in this case,
not in the 8 colors), Emacs uses color-translation to find the closest
color that is supported.  See tty-colors.el.  If this translation
doesn't produce satisfactory results, the face colors need to be
either:

  . changed such that (a) on color-rich terminals the colors are
    similar, but (b) on 8-color terminals we get better results; or
  . the face definition should be changed to have a separate setting
    of colors for terminals with 8 colors

> The face hi-green, for example, rather than having background
> "green" gets "light green".  This appears on the terminal as dark
> yellow, which is clearly wrong.

Why do you think it's wrong?  Given that yellow is closer to hi-green
(judging by its RGB components) than green, I see nothing wrong here.

> Also the face mode-line-inactive is indistinguishable from the default
> face

??? It should be the same as mode-line face of the active mode line.
I wonder how come it's the same as the default in your case.  Is that
in "emacs -Q"?

Re: Using Emacs in fbterm.

[Alan Mackenzie]

Hello, Eli.

On Mon, Aug 29, 2022 at 20:33:13 +0300, Eli Zaretskii wrote:
> > Date: Mon, 29 Aug 2022 16:41:00 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > There is a problem with colours in Emacs in fbterm.  When one does M-:
> > (defined-colors) it prints a list of just eight colours, black, red,
> > ...., white.
> > 
> > However, the face constructing mechanism seems to assume more than eight
> > colours, and this seems buggy.

> Face constructing makes no such assumptions.  If the colors defined
> for the face are not directly supported by the terminal (in this case,
> not in the 8 colors), Emacs uses color-translation to find the closest
> color that is supported.  See tty-colors.el.  If this translation
> doesn't produce satisfactory results, the face colors need to be
> either:

>   . changed such that (a) on color-rich terminals the colors are
>     similar, but (b) on 8-color terminals we get better results; or
>   . the face definition should be changed to have a separate setting
>     of colors for terminals with 8 colors

> > The face hi-green, for example, rather than having background
> > "green" gets "light green".  This appears on the terminal as dark
> > yellow, which is clearly wrong.

> Why do you think it's wrong?

hi-green MUST be green, otherwise, what's the point?  What is wrong is
the "light" in light green.  It's simply "green" on the Linux console.
Looking at the Lisp expression in customize-face, light green can only
happen when (min-colors 88) is satisfied.

> Given that yellow is closer to hi-green (judging by its RGB
> components) than green, I see nothing wrong here.

> > Also the face mode-line-inactive is indistinguishable from the default
> > face

> ??? It should be the same as mode-line face of the active mode line.
> I wonder how come it's the same as the default in your case.  Is that
> in "emacs -Q"?

It was, yes.

I've made further progress in diagnosing this.  If the environment
variable TERM is "linux", the problems with the colours don't happen.
If it's "fbterm", they do.

So, I would guess that somewhere in the depths of the face construction,
there's a test for TERM being "linux".  Or, maybe, an inappropriate
terminfo entry is getting used when it's "fbterm".  Or something like
that.  Maybe the fbterm terminfo entry is inconsistent with fbterm
itself.

I think it's worth fixing, whatever it is.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 18:44:26 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > The face hi-green, for example, rather than having background
> > > "green" gets "light green".  This appears on the terminal as dark
> > > yellow, which is clearly wrong.
> 
> > Why do you think it's wrong?
> 
> hi-green MUST be green, otherwise, what's the point?

Why, because of the textual similarity? that's a wrong way of finding
the best match for a color.  Long time ago what is now tty-colors.el
used such "heuristics", and it was found to be less satisfactory than
the current system based on RGB values.

So we won't go back to the sub-optimal method.

> What is wrong is the "light" in light green.  It's simply "green" on
> the Linux console.  Looking at the Lisp expression in
> customize-face, light green can only happen when (min-colors 88) is
> satisfied.

You are misinterpreting what the code does.  It doesn't work the way
you think it does.

Once again, if the results of automatic translation of colors are
unsatisfactory, we should do one of these:

   . change the colors such that (a) on color-rich terminals the
     colors are similar, but (b) on 8-color terminals we get better
     results; or
   . change the face definition to have a separate setting of colors
     for terminals with 8 colors

Please try to see which one of these gives better results, and let's
go with that.  Although...

> I've made further progress in diagnosing this.  If the environment
> variable TERM is "linux", the problems with the colours don't happen.
> If it's "fbterm", they do.

Which problems do or don't happen depending on $TERM?

> So, I would guess that somewhere in the depths of the face construction,
> there's a test for TERM being "linux".

I doubt that.

> Or, maybe, an inappropriate terminfo entry is getting used when it's
> "fbterm".  Or something like that.  Maybe the fbterm terminfo entry
> is inconsistent with fbterm itself.

That's possible, but also unlikely.  If terminfo is the problem, then
looking at the color commands that we send to the terminal (in term.c)
could perhaps point out the reason.

Re: Using Emacs in fbterm.

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]


>
> So, I would guess that somewhere in the depths of the face construction, 
> there's a test for TERM being "linux".  Or, maybe, an inappropriate 
> terminfo entry is getting used when it's "fbterm".  Or something like 
> that.  Maybe the fbterm terminfo entry is inconsistent with fbterm 
> itself.
>

Indeed, if I set TERM to fbterm I now see what you described.  Perhaps 
Emacs doesn't know that TERM=fbterm means that only eight colors are 
available?

>
> I think it's worth fixing, whatever it is.
>

Well, it's easy to fix: export TERM=linux 😉

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 18:54:39 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Indeed, if I set TERM to fbterm I now see what you described.  Perhaps 
> Emacs doesn't know that TERM=fbterm means that only eight colors are 
> available?

What does the terminfo DB say about commands to set color on fbterm?

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> Indeed, if I set TERM to fbterm I now see what you described.  Perhaps 
>> Emacs doesn't know that TERM=fbterm means that only eight colors are 
>> available?
>
> What does the terminfo DB say about commands to set color on fbterm?
>

Here's the comparison of the relevant entries between linux and fbterm. 
I don't know where the fbterm entries come from, they seem to be based on 
some patched version.

$ infocmp -d linux fbterm
colors: 8, 256.
pairs: 64, 32767.
initc: '\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x', '\E[3;%p1%d;%p2%d;%p3%d;%p4%d}'.
setab: '\E[4%p1%dm', '\E[2;%p1%d}'.
setaf: '\E[3%p1%dm', '\E[1;%p1%d}'.
setb: NULL, '\E[2;%p1%d}'.
setf: NULL, '\E[1;%p1%d}'.
sgr: '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;', '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m'.
sgr0: '\E[m\017', '\E[0;10m'.

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 19:29:32 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: acm@muc.de, emacs-devel@gnu.org
> 
> > What does the terminfo DB say about commands to set color on fbterm?
> >
> 
> Here's the comparison of the relevant entries between linux and fbterm. 
> I don't know where the fbterm entries come from, they seem to be based on 
> some patched version.

Not surprisingly, the differences are in color commands.

Re: Using Emacs in fbterm.

[Gregory Heytings]

>>> What does the terminfo DB say about commands to set color on fbterm?
>>
>> Here's the comparison of the relevant entries between linux and fbterm. 
>> I don't know where the fbterm entries come from, they seem to be based 
>> on some patched version.
>
> Not surprisingly, the differences are in color commands.
>

I guess the safest fix is to add an additional note about this in the FAQ 
entry?

Re: Using Emacs in fbterm.

[Gregory Heytings]

>>>> What does the terminfo DB say about commands to set color on fbterm?
>>> 
>>> Here's the comparison of the relevant entries between linux and 
>>> fbterm. I don't know where the fbterm entries come from, they seem to 
>>> be based on some patched version.
>> 
>> Not surprisingly, the differences are in color commands.
>
> I guess the safest fix is to add an additional note about this in the 
> FAQ entry?
>

And the details are in the manpage:

FbTerm supports xterm's 256 color mode extension. The first 16 colors are 
the default terminal colors. Additionally, there's a 6x6x6 color cube, and 
24 grayscale tones.  But xterm's 256 color escape sequences conflict with 
the linux sequences implemented by FbTerm, so private escape sequences 
were introduced to support this feature:

ESC [ 1 ; n }              set foreground color to n (0 - 255)
ESC [ 2 ; n }              set background color to n (0 - 255)
ESC [ 3 ; n ; r ; g ; b }  set color n to (r, g, b) ,  n, r, g, b all in (0 - 255)

A new terminfo database entry named "fbterm" was added to use these 
private sequences, all program based on terminfo should work with it.  By 
default, FbTerm sets environment variable "TERM" to value "linux", user 
need run "TERM=fbterm /path/to/program" to enable 256 color mode.

Apparently some distros have chosen to enable that 256 color mode by 
default.

Re: Using Emacs in fbterm.

[Andreas Schwab]

On Aug 29 2022, Gregory Heytings wrote:

> Indeed, if I set TERM to fbterm I now see what you described.  Perhaps
> Emacs doesn't know that TERM=fbterm means that only eight colors are
> available?

infocmp says it has 256 colors, which makes sense for a framebuffer
based terminal.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> Indeed, if I set TERM to fbterm I now see what you described.  Perhaps 
>> Emacs doesn't know that TERM=fbterm means that only eight colors are 
>> available?
>
> infocmp says it has 256 colors, which makes sense for a framebuffer 
> based terminal.
>

I don't think so.  It's framebuffer based indeed, so in theory it can 
support true (24 bit) colors.  In practice, text-based rendering is 
limited to the eight standard colors.

Re: Using Emacs in fbterm.

[Andreas Schwab]

On Aug 29 2022, Gregory Heytings wrote:

> I don't think so.  It's framebuffer based indeed, so in theory it can
> support true (24 bit) colors.  In practice, text-based rendering is
> limited to the eight standard colors.

What do you mean with "text-based rendering" and in which way is that a
limiting factor?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> I don't think so.  It's framebuffer based indeed, so in theory it can 
>> support true (24 bit) colors.  In practice, text-based rendering is 
>> limited to the eight standard colors.
>
> What do you mean with "text-based rendering" and in which way is that a 
> limiting factor?
>

I meant the rendering based on the standard ANSI escape sequences, which 
are used when programs run in a Linux console.  But you're right, it's not 
a limiting factor indeed, Emacs could be adapted to use the private escape 
sequences defined by fbterm.

Re: Using Emacs in fbterm.

[Alan Mackenzie]

Hello, Gregory.

On Mon, Aug 29, 2022 at 20:27:14 +0000, Gregory Heytings wrote:

> >> I don't think so.  It's framebuffer based indeed, so in theory it can 
> >> support true (24 bit) colors.  In practice, text-based rendering is 
> >> limited to the eight standard colors.
> >
> > What do you mean with "text-based rendering" and in which way is that a 
> > limiting factor?
> >

> I meant the rendering based on the standard ANSI escape sequences, which 
> are used when programs run in a Linux console.  But you're right, it's not 
> a limiting factor indeed, Emacs could be adapted to use the private escape 
> sequences defined by fbterm.

Why should Emacs need adapting?  Surely these terminfo entries for
fbterm's private colours should suffice for ncurses to display them
correctly.  Or am I missing something?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Using Emacs in fbterm.

[Gregory Heytings]

>
> Why should Emacs need adapting?  Surely these terminfo entries for 
> fbterm's private colours should suffice for ncurses to display them 
> correctly.  Or am I missing something?
>

I meant that (IIUC) an additional file should be added in lisp/term/ for 
fbterm, not that Emacs should itself send these escape sequences.  See the 
comment in lisp/term/tty-colors.el.

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> Why should Emacs need adapting?  Surely these terminfo entries for 
>> fbterm's private colours should suffice for ncurses to display them 
>> correctly.  Or am I missing something?
>
> I meant that (IIUC) an additional file should be added in lisp/term/ for 
> fbterm, not that Emacs should itself send these escape sequences.  See 
> the comment in lisp/term/tty-colors.el.
>

And here is a minimal patch to enable 256 colors under fbterm:

diff --git a/lisp/term/fbterm.el b/lisp/term/fbterm.el
new file mode 100644
index 0000000000..bf12b5ed97
--- /dev/null
+++ b/lisp/term/fbterm.el
@@ -0,0 +1,9 @@
+;;; fbterm.el  -*- lexical-binding:t -*-
+
+(require 'term/xterm)
+
+(defun terminal-init-fbterm ()
+  "Terminal initialization function for fbterm."
+  (xterm-register-default-colors xterm-standard-colors))
+
+(provide 'term/fbterm)

Eli, what else would you recommend to add in that file?  I think 
(tty-no-underline)?  And how can I check whether compositions should be 
disabled, that is, if they confuse cursor movement?

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 22:28:43 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>, 
>     emacs-devel@gnu.org
> 
> And here is a minimal patch to enable 256 colors under fbterm:
> 
> diff --git a/lisp/term/fbterm.el b/lisp/term/fbterm.el
> new file mode 100644
> index 0000000000..bf12b5ed97
> --- /dev/null
> +++ b/lisp/term/fbterm.el
> @@ -0,0 +1,9 @@
> +;;; fbterm.el  -*- lexical-binding:t -*-
> +
> +(require 'term/xterm)
> +
> +(defun terminal-init-fbterm ()
> +  "Terminal initialization function for fbterm."
> +  (xterm-register-default-colors xterm-standard-colors))
> +
> +(provide 'term/fbterm)

But since fbterm doesn't always announce itself as such, but instead
calls itself "linux", this is not reliable enough, is it?

> Eli, what else would you recommend to add in that file?  I think 
> (tty-no-underline)?

If it doesn't support underline, yes.

> And how can I check whether compositions should be disabled, that
> is, if they confuse cursor movement?

There are some compositions in HELLO, and you can also try some long
Emoji sequences.

Re: Using Emacs in fbterm.

[Gregory Heytings]

>
> But since fbterm doesn't always announce itself as such, but instead 
> calls itself "linux", this is not reliable enough, is it?
>

It is.  There are two cases: if it calls itself "linux", you get eight 
colors, and everything works as expected with those eight colors.  If it 
calls itself "fbterm", you get wrong colors (without the patch).

(And of course we can also tell users to set TERM=fbterm in the FAQ 
entry.)

>> And how can I check whether compositions should be disabled, that is, 
>> if they confuse cursor movement?
>
> There are some compositions in HELLO, and you can also try some long 
> Emoji sequences.
>

As far as I can tell, cursor movement works as expected with 
auto-composition-mode t.

So I suggest the following patch, with an additional note in the FAQ 
entry.

diff --git a/lisp/term/fbterm.el b/lisp/term/fbterm.el
new file mode 100644
index 0000000000..2e66bb72c0
--- /dev/null
+++ b/lisp/term/fbterm.el
@@ -0,0 +1,21 @@
+;;; fbterm.el  -*- lexical-binding:t -*-
+
+(require 'term/xterm)
+
+(declare-function gpm-mouse-enable "t-mouse" ())
+
+(defun terminal-init-fbterm ()
+  "Terminal initialization function for fbterm."
+
+  ;; fbterm can't display underlines, even though its terminfo data
+  ;; says it can.
+  (tty-no-underline)
+
+  ;; fbterm supports xterm's 256 color mode extension.
+  (xterm-register-default-colors xterm-standard-colors)
+
+  (ignore-errors (when gpm-mouse-mode (require 't-mouse) (gpm-mouse-enable))))
+
+(provide 'term/fbterm)
+
+;;; fbterm.el ends here

Re: Using Emacs in fbterm.

[Eli Zaretskii]

> Date: Tue, 30 Aug 2022 12:04:24 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: acm@muc.de, schwab@linux-m68k.org, emacs-devel@gnu.org
> 
> > But since fbterm doesn't always announce itself as such, but instead 
> > calls itself "linux", this is not reliable enough, is it?
> 
> It is.  There are two cases: if it calls itself "linux", you get eight 
> colors, and everything works as expected with those eight colors.  If it 
> calls itself "fbterm", you get wrong colors (without the patch).
>
> (And of course we can also tell users to set TERM=fbterm in the FAQ 
> entry.)

Maybe it's worth telling this in a comment in fbterm.el?  I mean that
if the user's fbterm doesn't identify itself as such, they will get
only 8 colors, unless they fiddle with the environment.

> >> And how can I check whether compositions should be disabled, that is, 
> >> if they confuse cursor movement?
> >
> > There are some compositions in HELLO, and you can also try some long 
> > Emoji sequences.
> >
> 
> As far as I can tell, cursor movement works as expected with 
> auto-composition-mode t.
> 
> So I suggest the following patch, with an additional note in the FAQ 
> entry.

Thanks, this is fine by me.

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> So I suggest the following patch, with an additional note in the FAQ 
>> entry.
>
> Thanks, this is fine by me.
>

Now done (commit 8807a4f532).

Re: Using Emacs in fbterm.

[Stefan Monnier]

> +;;; fbterm.el  -*- lexical-binding:t -*-
> +
> +(require 'term/xterm)

This lacks the usual license blurb, of course, but I think more
importantly it would benefit from a `Commentary:` explaining the
relationship between color support and the fbterm running with
TERM=linux or TERM=fbterm.

> +  (ignore-errors (when gpm-mouse-mode (require 't-mouse) (gpm-mouse-enable))))

Hmm... this seems to point to a problem/shortcoming in `t-mouse.el`
which should arguably do that automatically, no?


        Stefan

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> +;;; fbterm.el  -*- lexical-binding:t -*-
>> +
>> +(require 'term/xterm)
>
> This lacks the usual license blurb, of course
>

Short files in lisp/term/ do not have that license blurb, I thought it was 
on purpose?

>> + (ignore-errors (when gpm-mouse-mode (require 't-mouse) (gpm-mouse-enable))))
>
> Hmm... this seems to point to a problem/shortcoming in `t-mouse.el` 
> which should arguably do that automatically, no?
>

I confess I blindly copied that line from linux.el, thinking it was 
probably useful for something.  After some testing it doesn't seem to make 
a difference, so I'll just remove it.

Re: Using Emacs in fbterm.

[Stefan Monnier]

>>> +;;; fbterm.el  -*- lexical-binding:t -*-
>>> +(require 'term/xterm)
>> This lacks the usual license blurb, of course
> Short files in lisp/term/ do not have that license blurb, I thought it was
> on purpose?

Hmm..... interesting.  I don't know what should be done in this respect.
But the important thing is to explain/document the why of the code so
that 10 years from now someone will know how to maintain it.

>>> + (ignore-errors (when gpm-mouse-mode (require 't-mouse) (gpm-mouse-enable))))
>> Hmm... this seems to point to a problem/shortcoming in `t-mouse.el` which
>> should arguably do that automatically, no?
> I confess I blindly copied that line from linux.el, thinking it was
> probably useful for something.

It should probably be removed from there as well.  If it causes
a regression that should be fixed in `t-mouse.el` or at the very least
come with a clear description of the problem it fixes.

> After some testing it doesn't seem to make a difference, so I'll just
> remove it.

Great, thanks,


        Stefan

Re: Using Emacs in fbterm.

[Gregory Heytings]

>>> Hmm... this seems to point to a problem/shortcoming in `t-mouse.el` 
>>> which should arguably do that automatically, no?
>>
>> I confess I blindly copied that line from linux.el, thinking it was 
>> probably useful for something.
>
> It should probably be removed from there as well.  If it causes a 
> regression that should be fixed in `t-mouse.el` or at the very least 
> come with a clear description of the problem it fixes.
>

I cannot do that on the release branch, but feel free to do so on master. 
Note that the two last commits which modified that line are yours.  The 
ignore-errors appears to come from 4a364c5ef2: "Don't signal an error if 
gpm isn't running."  It seems to me that indeed t-mouse.el already handles 
that case by itself, but I'm not 110% sure.

Re: Using Emacs in fbterm.

[Stefan Monnier]

> I cannot do that on the release branch, but feel free to do so on
> master.  Note that the two last commits which modified that line are yours.

Can't be me.  Must have been some confused namesake or someone who
hacked my account.

> The ignore-errors appears to come from 4a364c5ef2: "Don't signal an error if
> gpm isn't running."  It seems to me that indeed t-mouse.el already handles
> that case by itself, but I'm not 110% sure.

OK, I think I found the reason for that code and I installed a fix in
`master`.


        Stefan

Re: Using Emacs in fbterm.

[Gregory Heytings]

>> I cannot do that on the release branch, but feel free to do so on 
>> master.  Note that the two last commits which modified that line are 
>> yours.
>
> Can't be me. Must have been some confused namesake or someone who hacked 
> my account.
>

Could it be Stfean then?

>> The ignore-errors appears to come from 4a364c5ef2: "Don't signal an 
>> error if gpm isn't running."  It seems to me that indeed t-mouse.el 
>> already handles that case by itself, but I'm not 110% sure.
>
> OK, I think I found the reason for that code and I installed a fix in 
> `master`.
>

Thanks!  You forgot to remove the '(declare-function gpm-mouse-enable 
"t-mouse" ())' in lisp/term/linux.el (I think).

Re: Using Emacs in fbterm.

[Stefan Monnier]

>>> I cannot do that on the release branch, but feel free to do so on master.
>>> Note that the two last commits which modified that line are yours.
>> Can't be me. Must have been some confused namesake or someone who hacked
>> my account.
> Could it be Stfean then?

:-)

>>> The ignore-errors appears to come from 4a364c5ef2: "Don't signal an error
>>> if gpm isn't running."  It seems to me that indeed t-mouse.el already
>>> handles that case by itself, but I'm not 110% sure.
>> OK, I think I found the reason for that code and I installed a fix in
>> `master`.
> Thanks!  You forgot to remove the '(declare-function gpm-mouse-enable
> "t-mouse" ())' in lisp/term/linux.el (I think).

Fixed, thanks,


        Stefan

Re: Using Emacs in fbterm.

[Gregory Heytings]

>
> There is a problem with colours in Emacs in fbterm.  When one does M-: 
> (defined-colors) it prints a list of just eight colours, black, red, 
> ...., white.
>

That's expected, isn't it?  The Linux console only supports eight colors. 
Or do you have more colors when you run Emacs without fbterm?

>
> However, the face constructing mechanism seems to assume more than eight 
> colours, and this seems buggy.  The face hi-green, for example, rather 
> than having background "green" gets "light green".  This appears on the 
> terminal as dark yellow, which is clearly wrong.
>

That's not what I see here, hi-green is green (#00aa00).  I know there's a 
patch for fbterm somewhere which adds the possibility to modify the color 
palette.  Perhaps it's included in the fbterm included your distro, and 
somehow changes the appearance of the green color?

>
> Also the face mode-line-inactive is indistinguishable from the default 
> face, so when there're more than one window in the frame, they are less 
> easy to distinguish than they should be.
>

I guess you mean that the mode-line-inactive is indistinguishable from the 
mode-line face?  Is that different from what you seen when you run Emacs 
without fbterm?