bug#16656: [PATCH] Detect XTerm versions for non-VT100 emulation modes

bug#16656: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

* term/xterm.el (xterm--version-handler): Handle cases where the
  terminal type is not zero.  The three numbers in the {CSI}>{Ps}c
  response are: Pp (terminal type), Pv (firmware version), and Pc
  (always zero for xterm).  Before this commit, Emacs only looked at
  Pv if Pp was zero (VT100).  However, for XTerm v280 and later, the
  default emulation is for VT420 (Pp = 41).  See the XTerm changelog
  for details:
  http://invisible-island.net/xterm/xterm.log-contents.html#xterm_280
---
 lisp/term/xterm.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 87f8c96..3d1b28b 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -500,8 +500,8 @@ The relevant features are:
     ;; see if by using a longer timeout we get rid of most issues.
     (while (and (setq chr (read-event nil nil 2)) (not (equal chr ?c)))
       (setq str (concat str (string chr))))
-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)
-- 
1.8.5.2.8.g0f6c0d1

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

* term/xterm.el (xterm--version-handler): Handle cases where the
  terminal type is not zero.  The three numbers in the {CSI}>{Ps}c
  response are: Pp (terminal type), Pv (firmware version), and Pc
  (always zero for xterm).  Before this commit, Emacs only looked at
  Pv if Pp was zero (VT100).  However, for XTerm v280 and later, the
  default emulation is for VT420 (Pp = 41).  See the XTerm changelog
  for details:
  http://invisible-island.net/xterm/xterm.log-contents.html#xterm_280
---
I sent this in a few hours ago, but it doesn't look like it made it to
the list.  I wasn't subscribed to the list then, so it's possible the
original is queued for moderator approval.  I didn't get any message
to that effect though, so I just signed up and am sending this
resubmission ;).

Another useful link (the source for my control code information) is
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html, but I didn't
work that into my commit message.  Let me know if that's worth a
resubmit.

Cheers,
Trevor

 lisp/term/xterm.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 87f8c96..3d1b28b 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -500,8 +500,8 @@ The relevant features are:
     ;; see if by using a longer timeout we get rid of most issues.
     (while (and (setq chr (read-event nil nil 2)) (not (equal chr ?c)))
       (setq str (concat str (string chr))))
-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)
-- 
1.8.5.2.8.g0f6c0d1

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[Glenn Morris]

"W. Trevor King" wrote:

> so it's possible the original is queued for moderator approval.

Exactly. (There is no need to subscribe just to post BTW.)

> I didn't get any message to that effect though, so I just signed up
> and am sending this resubmission ;).

A better procedure is just to wait a bit. We don't send out "your
message is held for moderation" notices, since most things that get held
for moderation are spam.

Anyway, I will delete

http://debbugs.gnu.org/16656

since it is a duplicate of this.

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

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

On Wed, Feb 05, 2014 at 04:40:24PM -0500, Glenn Morris wrote:
> "W. Trevor King" wrote:
> > so it's possible the original is queued for moderator approval.
> 
> Exactly. (There is no need to subscribe just to post BTW.)

A note somewhere ([1], [2], or [3]?) that makes this explicit would be
nice.

> > I didn't get any message to that effect though, so I just signed
> > up and am sending this resubmission ;).
> 
> A better procedure is just to wait a bit.

Sorry.  I was too excited at figuring out why my background-mode
wasn't dark :p.  I'll be more patient next time.

> Anyway, I will delete
> 
> http://debbugs.gnu.org/16656
> 
> since it is a duplicate of this.

Thanks,
Trevor

[1]: https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
[2]: http://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html
[3]: http://www.gnu.org/software/emacs/CONTRIBUTE

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

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

This issue is also mentioned in some of the comments from the tail of
#13839 [1,2,3].  Victor even quoted the XTerm changelog :p.  I don't
see a patch for this particular issue in #13839, although Stefan posts
a patch for some other keymap stuff, and Victor floats an alternate
regexp [1].

[1]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839#11
[2]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839#14
[3]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839#17

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[Glenn Morris]

"W. Trevor King" wrote:

> A note somewhere ([1], [2], or [3]?) that makes this explicit would be
> nice.

What I am saying is common to basically every GNU mailing list.
Even if you subscribe, you still need to wait for moderation at least
the first time. I think/hope this is standard practice for all sane
public mailing lists. Ie, everybody except Debian's? ;)

FWIW, "Checklist for Bug Reports"

http://www.gnu.org/software/emacs/manual/html_node/emacs/Checklist.html

does say "Submissions are moderated, so there may be a delay before your
report appears."

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

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

On Thu, Feb 06, 2014 at 10:39:34PM -0500, Glenn Morris wrote:
> FWIW, "Checklist for Bug Reports"
> 
> http://www.gnu.org/software/emacs/manual/html_node/emacs/Checklist.html
> 
> does say "Submissions are moderated, so there may be a delay before your
> report appears."

Ah, it certainly does.  Sorry I missed that.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[W. Trevor King]

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

Is there anything I can do to help this along?  I'm happy to add
clarifying information to the commit message if that would help.  In
13839, Stefan expressed concern over non-XTerms that claim to be XTerm
[1]:

On Mon, Mar 11, 2013 at 14:25:30 -0400, Stefan Monnier wrote:
> More specifically, I'm concerned that by accepting any "P p" number,
> we might end up trying to use a feature that's not supported by the
> underlying terminal emulator because it happens to have version
> numbers that are higher than those of "the usual xterm".

Lacking a spec for XTerm impersonators, it's hard to address this
directly.  However, as it stands, version detection is broken for
XTerm ≥ v280, and I think that fixing that known breakage for the true
XTerm is more important than avoiding hypothetical breakage for
impersonators.  Are there other concerns with the logic here?  If so,
what sort of research might help clear them up?  Are there some common
impersonators that I should investigate directly?

Cheers,
Trevor

[1]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839#14

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[Stefan Monnier]

> Is there anything I can do to help this along?

Do you have a few spare hours, maybe?


        Stefan

bug#16657: [PATCH] Detect XTerm versions for non-VT100 emulation modes

[Stefan Monnier]

> * term/xterm.el (xterm--version-handler): Handle cases where the
>   terminal type is not zero.  The three numbers in the {CSI}>{Ps}c
>   response are: Pp (terminal type), Pv (firmware version), and Pc
>   (always zero for xterm).  Before this commit, Emacs only looked at
>   Pv if Pp was zero (VT100).  However, for XTerm v280 and later, the
>   default emulation is for VT420 (Pp = 41).  See the XTerm changelog
>   for details:
>   http://invisible-island.net/xterm/xterm.log-contents.html#xterm_280

Thanks, I installed your patch.


        Stefan