support for rxvt-unicode in rxvt.el

support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

The patch that follows modifies rxvt.el and creates a 'rxvt-unicode.el'
file to add support for the rxvt-unicode terminal emulator.  This
terminal has its own terminfo description, and supports 88 colors (the
4x4x4 cube of xterm compiled with --enable-88-color).  The differences
from rxvt, at this level, are in the escape sequences for the cursor
keys (the same ones xterm uses in application mode) and in the number of
supported colors (I've taken the code to generate them from xterm.el).

--- rxvt-unicode.el	1970-01-01 01:00:00.000000000 +0100
+++ rxvt-unicode.el	2005-09-21 14:21:55.000000000 +0200
@@ -0,0 +1,2 @@
+(defun terminal-init-rxvt-unicode ()
+  (load "term/rxvt" nil t))
--- rxvt.el	2005-09-21 13:02:55.000000000 +0200
+++ rxvt.el	2005-09-21 14:47:44.000000000 +0200
@@ -146,13 +146,19 @@
     (define-key map "\e[3$" [S-delete])
     (define-key map "\e[5$" [S-prior])
     (define-key map "\e[6$" [S-next])
-    (define-key map "\e[8$" [S-end])
     (define-key map "\e[7$" [S-home])
+    (define-key map "\e[8$" [S-end])
     (define-key map "\e[d" [S-left])
     (define-key map "\e[c" [S-right])
     (define-key map "\e[a" [S-up])
     (define-key map "\e[b" [S-down])
 
+    ;; rxvt-unicode uses these key definitions for the cursor keys
+    (define-key map "\eOA" [up])
+    (define-key map "\eOB" [down])
+    (define-key map "\eOC" [right])
+    (define-key map "\eOD" [left])
+
     ;; Use inheritance to let the main keymap override those defaults.
     ;; This way we don't override terminfo-derived settings or settings
     ;; made in the .emacs file.
@@ -210,6 +216,36 @@
       (setq colors (cdr colors)
 	    color (car colors)
 	    ncolors (1- ncolors)))
+    (when (and (> ncolors 0) (= ncolors 72))  ; rxvt-unicode
+      ;; 64 non-gray colors
+      (let ((levels '(0 139 205 255))
+	    (r 0) (g 0) (b 0))
+	(while (> ncolors 8)
+	  (tty-color-define (format "color-%d" (- 88 ncolors))
+			    (- 88 ncolors)
+			    (mapcar 'rxvt-rgb-convert-to-16bit
+				    (list (nth r levels)
+					  (nth g levels)
+					  (nth b levels))))
+	  (setq b (1+ b))
+	  (if (> b 3)
+	      (setq g (1+ g)
+		    b 0))
+	  (if (> g 3)
+	      (setq r (1+ r)
+		    g 0))
+	  (setq ncolors (1- ncolors))))
+      ;; Now the 8 gray colors
+      (while (> ncolors 0)
+	(setq color (rxvt-rgb-convert-to-16bit
+		     (floor
+		      (if (= ncolors 8)
+			  46.36363636
+			(+ (* (- 8 ncolors) 23.18181818) 69.54545454)))))
+	(tty-color-define (format "color-%d" (- 88 ncolors))
+			  (- 88 ncolors)
+			  (list color color color))
+	(setq ncolors (1- ncolors))))
     ;; Modifying color mappings means realized faces don't use the
     ;; right colors, so clear them.
     (clear-face-cache)))

Re: support for rxvt-unicode in rxvt.el

[Stefan Monnier]

> --- rxvt-unicode.el	1970-01-01 01:00:00.000000000 +0100
> +++ rxvt-unicode.el	2005-09-21 14:21:55.000000000 +0200
> @@ -0,0 +1,2 @@
> +(defun terminal-init-rxvt-unicode ()
> +  (load "term/rxvt" nil t))

What is this for?


        Stefan

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > --- rxvt-unicode.el   1970-01-01 01:00:00.000000000 +0100
> > +++ rxvt-unicode.el   2005-09-21 14:21:55.000000000 +0200
> > @@ -0,0 +1,2 @@
> > +(defun terminal-init-rxvt-unicode ()
> > +  (load "term/rxvt" nil t))
>
> What is this for?

Sorry, I forgot that emacs strips the hyphen and what follows if
term/${TERM}.el does not exist.

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

>  from rxvt, at this level, are in the escape sequences for the cursor
>  keys (the same ones xterm uses in application mode) and in the number of
>  supported colors (I've taken the code to generate them from xterm.el).

Are you sure that using the xterm code is correct for rxvt-unicode? At
least for the 256 color version xterm and rxvt use different
colors... 

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Are you sure that using the xterm code is correct for rxvt-unicode? At
> least for the 256 color version xterm and rxvt use different
> colors...

There is no 256 color version of rxvt-unicode; it supports exactly 88 colors.

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

Emanuele Giaquinta <emanuele.giaquinta@gmail.com> writes:

  > On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > Are you sure that using the xterm code is correct for rxvt-unicode? At
  > > least for the 256 color version xterm and rxvt use different
  > > colors...
  > 
  > There is no 256 color version of rxvt-unicode; it supports exactly
  > 88 colors.

What I meant is that the 256 color version of xterm and the 256 color
version of rxvt use different colors. 
Are you sure that the 88 color version of both xterm and rxvt use the
same colors? 
Because if they don't, then you cannot use the xterm code to compute
the colors for rxvt-unicode.

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Are you sure that the 88 color version of both xterm and rxvt use the
> same colors?

Yes; rxvt-unicode, as I've already said, defines the 88 colors of the
4x4x4 cube of xterm.

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

Emanuele Giaquinta <emanuele.giaquinta@gmail.com> writes:

  > On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > Are you sure that the 88 color version of both xterm and rxvt use the
  > > same colors?
  > 
  > Yes; rxvt-unicode, as I've already said, defines the 88 colors of
  > the 4x4x4 cube of xterm.

Thanks, I wanted to double check. rxvt says it does a lot of things
like xterm, but in fact that is not true... 

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

>  --- rxvt.el	2005-09-21 13:02:55.000000000 +0200
>  +++ rxvt.el	2005-09-21 14:47:44.000000000 +0200
>  @@ -146,13 +146,19 @@
>       (define-key map "\e[3$" [S-delete])
>       (define-key map "\e[5$" [S-prior])
>       (define-key map "\e[6$" [S-next])
>  -    (define-key map "\e[8$" [S-end])
>       (define-key map "\e[7$" [S-home])
>  +    (define-key map "\e[8$" [S-end])
>       (define-key map "\e[d" [S-left])
>       (define-key map "\e[c" [S-right])
>       (define-key map "\e[a" [S-up])
>       (define-key map "\e[b" [S-down])
>   
>  +    ;; rxvt-unicode uses these key definitions for the cursor keys
>  +    (define-key map "\eOA" [up])
>  +    (define-key map "\eOB" [down])
>  +    (define-key map "\eOC" [right])
>  +    (define-key map "\eOD" [left])
>  +
>       ;; Use inheritance to let the main keymap override those defaults.
>       ;; This way we don't override terminfo-derived settings or settings
>       ;; made in the .emacs file.
>  @@ -210,6 +216,36 @@
>         (setq colors (cdr colors)
>   	    color (car colors)
>   	    ncolors (1- ncolors)))
>  +    (when (and (> ncolors 0) (= ncolors 72))  ; rxvt-unicode
>  +      ;; 64 non-gray colors
>  +      (let ((levels '(0 139 205 255))
>  +	    (r 0) (g 0) (b 0))
>  +	(while (> ncolors 8)
>  +	  (tty-color-define (format "color-%d" (- 88 ncolors))
>  +			    (- 88 ncolors)
>  +			    (mapcar 'rxvt-rgb-convert-to-16bit
>  +				    (list (nth r levels)
>  +					  (nth g levels)
>  +					  (nth b levels))))
>  +	  (setq b (1+ b))
>  +	  (if (> b 3)
>  +	      (setq g (1+ g)
>  +		    b 0))
>  +	  (if (> g 3)
>  +	      (setq r (1+ r)
>  +		    g 0))
>  +	  (setq ncolors (1- ncolors))))
>  +      ;; Now the 8 gray colors
>  +      (while (> ncolors 0)
>  +	(setq color (rxvt-rgb-convert-to-16bit
>  +		     (floor
>  +		      (if (= ncolors 8)
>  +			  46.36363636
>  +			(+ (* (- 8 ncolors) 23.18181818) 69.54545454)))))
>  +	(tty-color-define (format "color-%d" (- 88 ncolors))
>  +			  (- 88 ncolors)
>  +			  (list color color color))
>  +	(setq ncolors (1- ncolors))))

If these are all the changes you need, then probably you don't need a
new term/rxvt-unicode.el file. 
The up, down, right and left key should be set from the rxvt-unicode terminfo
entry, so you don't need those define-keys. So if you just add the
color setting code to rxvt.el then everything should work. Can you
verify that the above is indeed true? 
IMHO it is better to avoid code duplication... 

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> If these are all the changes you need, then probably you don't need a
> new term/rxvt-unicode.el file.

In fact this is a patch to rxvt.el.

> The up, down, right and left key should be set from the rxvt-unicode terminfo
> entry, so you don't need those define-keys. So if you just add the
> color setting code to rxvt.el then everything should work. Can you
> verify that the above is indeed true?
> IMHO it is better to avoid code duplication...

I perfectly agree with you here; I've already tested it without
defining the sequences for the cursor keys, and, as expected, emacs
gets them from the terminfo entry.  I have added them only for
simmetry with the existing code in rxvt.el and xterm.el.  If there is
no good reason, the existing definitions for the cursor keys in
rxvt.el and xterm.el could be deleted.

Re: support for rxvt-unicode in rxvt.el

[Stefan Monnier]

>> The up, down, right and left key should be set from the rxvt-unicode
>> terminfo entry, so you don't need those define-keys. So if you just add
>> the color setting code to rxvt.el then everything should work.  Can you
>> verify that the above is indeed true?  IMHO it is better to avoid code
>> duplication...

> I perfectly agree with you here; I've already tested it without
> defining the sequences for the cursor keys, and, as expected, Emacs
> gets them from the terminfo entry.  I have added them only for
> symmetry with the existing code in rxvt.el and xterm.el.  If there is
> no good reason, the existing definitions for the cursor keys in
> rxvt.el and xterm.el could be deleted.

Such key sequences have been added to xterm.el because at some point they've
been found to be necessary.  Maybe nowadays they're redundant.  If they're
not necessary for rxvt.el, better not add them.  Removing them from xterm.el
is more delicate since we'd need to know for sure that they're
always unnecessary, otherwise we might (re)introduce bugs.


        Stefan "who doesn't know whether they may actually be necessary in
                rxvt.el in some cases"


PS: Before I can install your patch, I need for someone to tell me whether
I can do it: OT1H it seems you haven't signed any legal paperwork, OTOH your
code is just a copy of code from xterm.el.  Can I just install it as a "tiny
change"?

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Such key sequences have been added to xterm.el because at some point they've
> been found to be necessary.  Maybe nowadays they're redundant.  If they're
> not necessary for rxvt.el, better not add them.  Removing them from xterm.el
> is more delicate since we'd need to know for sure that they're
> always unnecessary, otherwise we might (re)introduce bugs.

Fine, follows an updated patch.
BTW I've noticed Dan has changed the definitions of white and
brightblack in rxvt.el; Dan, what is the reason for this change? The
previous ones were the definitions of rxvt.

--- rxvt.el	2005-09-21 13:02:55.000000000 +0200
+++ rxvt.el	2005-09-21 21:39:13.000000000 +0200
@@ -146,8 +146,8 @@
     (define-key map "\e[3$" [S-delete])
     (define-key map "\e[5$" [S-prior])
     (define-key map "\e[6$" [S-next])
-    (define-key map "\e[8$" [S-end])
     (define-key map "\e[7$" [S-home])
+    (define-key map "\e[8$" [S-end])
     (define-key map "\e[d" [S-left])
     (define-key map "\e[c" [S-right])
     (define-key map "\e[a" [S-up])
@@ -210,6 +210,36 @@
       (setq colors (cdr colors)
 	    color (car colors)
 	    ncolors (1- ncolors)))
+    (when (and (> ncolors 0) (= ncolors 72))  ; rxvt-unicode
+      ;; 64 non-gray colors
+      (let ((levels '(0 139 205 255))
+	    (r 0) (g 0) (b 0))
+	(while (> ncolors 8)
+	  (tty-color-define (format "color-%d" (- 88 ncolors))
+			    (- 88 ncolors)
+			    (mapcar 'rxvt-rgb-convert-to-16bit
+				    (list (nth r levels)
+					  (nth g levels)
+					  (nth b levels))))
+	  (setq b (1+ b))
+	  (if (> b 3)
+	      (setq g (1+ g)
+		    b 0))
+	  (if (> g 3)
+	      (setq r (1+ r)
+		    g 0))
+	  (setq ncolors (1- ncolors))))
+      ;; Now the 8 gray colors
+      (while (> ncolors 0)
+	(setq color (rxvt-rgb-convert-to-16bit
+		     (floor
+		      (if (= ncolors 8)
+			  46.36363636
+			(+ (* (- 8 ncolors) 23.18181818) 69.54545454)))))
+	(tty-color-define (format "color-%d" (- 88 ncolors))
+			  (- 88 ncolors)
+			  (list color color color))
+	(setq ncolors (1- ncolors))))
     ;; Modifying color mappings means realized faces don't use the
     ;; right colors, so clear them.
     (clear-face-cache)))

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

Emanuele Giaquinta <emanuele.giaquinta@gmail.com> writes:

  > On 9/21/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
  > 
  > > Such key sequences have been added to xterm.el because at some point they've
  > > been found to be necessary.  Maybe nowadays they're redundant.  If they're
  > > not necessary for rxvt.el, better not add them.  Removing them from xterm.el
  > > is more delicate since we'd need to know for sure that they're
  > > always unnecessary, otherwise we might (re)introduce bugs.
  > 
  > Fine, follows an updated patch.
  > BTW I've noticed Dan has changed the definitions of white and
  > brightblack in rxvt.el; Dan, what is the reason for this change? The
  > previous ones were the definitions of rxvt.

The new definitions correspond to the colors emitted by rxvt. 
(You can take a screen dump and check if you want). 

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/21/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> The new definitions correspond to the colors emitted by rxvt.
> (You can take a screen dump and check if you want).

Sorry, I have just checked rxvt sources; it uses the previous
definitions only if the macro XTERM_COLORS, which is by default
defined in feature.h, is not defined.

Re: support for rxvt-unicode in rxvt.el

[Dan Nicolaescu]

Hi, 

I got word that is OK to install your patch, so I did that. 
I did not install the part that adds key bindings as it does not seem
to be needed. If the key bindings prove to be necessary we can install
them later.

Thank you for your contribution!

         --Dan

Re: support for rxvt-unicode in rxvt.el

[Emanuele Giaquinta]

On 9/25/05, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> I got word that is OK to install your patch, so I did that.
> I did not install the part that adds key bindings as it does not seem
> to be needed. If the key bindings prove to be necessary we can install
> them later.

Very good; as Andreas pointed out, there is a redundant check on ncolors.
Thanks.

Index: rxvt.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/term/rxvt.el,v
retrieving revision 1.14
diff -u -r1.14 rxvt.el
--- rxvt.el     24 Sep 2005 23:20:45 -0000      1.14
+++ rxvt.el     25 Sep 2005 00:15:15 -0000
@@ -240,7 +240,7 @@
                    (list color color color))
       (setq ncolors (1- ncolors))))

-       ((and (> ncolors 0) (= ncolors 72)) ; rxvt-unicode
+       ((= ncolors 72) ; rxvt-unicode
     ;; 64 non-gray colors
     (let ((levels '(0 139 205 255))
           (r 0) (g 0) (b 0))

Re: support for rxvt-unicode in rxvt.el

[Andreas Schwab]

Emanuele Giaquinta <emanuele.giaquinta@gmail.com> writes:

> @@ -210,6 +210,36 @@
>        (setq colors (cdr colors)
>  	    color (car colors)
>  	    ncolors (1- ncolors)))
> +    (when (and (> ncolors 0) (= ncolors 72))  ; rxvt-unicode
                  ^^^^^^^^^^^^^
This is redundant.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."