read a reply from the terminal

read a reply from the terminal

[Dan Nicolaescu]

I trying to do: (send-string-to-terminal "\e[>0c") and read the string
that the terminal sends back. Can this be done reliably in elisp?


The reason I want this is because I want to enable 
"modifyOtherString" at runtime in term/xterm.el (it can be done by
sending an escape sequence to the terminal).

But not all terminals that set TERM to xterm support
modifyOtherString. By querying the terminal I can find out if it is
indeed an xterm and send the escape sequence to enable
modifyOtherString.

Re: read a reply from the terminal

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Fri, 13 Jul 2007 19:42:51 -0700
> 
> I trying to do: (send-string-to-terminal "\e[>0c") and read the string
> that the terminal sends back. Can this be done reliably in elisp?

If you know exactly how many bytes will the response include, I think
insert-file-contents should fit the bill.  Doesn't it?

Re: read a reply from the terminal

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@ics.uci.edu>
>> Date: Fri, 13 Jul 2007 19:42:51 -0700
>> 
>> I trying to do: (send-string-to-terminal "\e[>0c") and read the string
>> that the terminal sends back. Can this be done reliably in elisp?
>
> If you know exactly how many bytes will the response include, I think
> insert-file-contents should fit the bill.  Doesn't it?

How?

-- 
Johan Bockgård

Re: read a reply from the terminal

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Sun, 15 Jul 2007 15:49:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Dan Nicolaescu <dann@ics.uci.edu>
> >> Date: Fri, 13 Jul 2007 19:42:51 -0700
> >> 
> >> I trying to do: (send-string-to-terminal "\e[>0c") and read the string
> >> that the terminal sends back. Can this be done reliably in elisp?
> >
> > If you know exactly how many bytes will the response include, I think
> > insert-file-contents should fit the bill.  Doesn't it?
> 
> How?

How what?  Sorry, I really don't understand the question.

In any case, Stefan suggested a different solution which Dan decided
to use.

Re: read a reply from the terminal

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> How what?  Sorry, I really don't understand the question.

How can insert-file-contents be used to read a reply from the terminal
(if you know how many bytes it contains). It sounded like you had a
solution in mind.

-- 
Johan Bockgård

Re: read a reply from the terminal

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Mon, 16 Jul 2007 00:04:43 +0200
> 
> How can insert-file-contents be used to read a reply from the terminal
> (if you know how many bytes it contains). It sounded like you had a
> solution in mind.

The terminal can be addressed by name (its device driver name,
something like "/dev/tty1"), right?  If so, you can read from that
device as if it were a file.  insert-file-contents is a way to read
from files, and it supports reading a certain number of bytes.

Re: read a reply from the terminal

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> The terminal can be addressed by name (its device driver name,
> something like "/dev/tty1"), right?  If so, you can read from that
> device as if it were a file.  insert-file-contents is a way to read
> from files, and it supports reading a certain number of bytes.

Ok. But it does not support reading a specified number of bytes when
the file is non-regular. (It would be useful if it could.)

  if (!S_ISREG (st.st_mode))
    {
      not_regular = 1;
      [...]
      if (! NILP (replace) || ! NILP (beg) || ! NILP (end))
      xsignal2 (Qfile_error,
                 build_string ("not a regular file"), orig_filename);
    }

The manual says

     It is possible to read a special file (such as a FIFO or an I/O
     device) with `insert-file-contents', as long as REPLACE and VISIT
     are `nil'.

It should be added that BEG and END have to be nil as well, or someone
might want to improve the code.

-- 
Johan Bockgård

Re: read a reply from the terminal

[Stefan Monnier]

> I trying to do: (send-string-to-terminal "\e[>0c") and read the string
> that the terminal sends back.  Can this be done reliably in elisp?

Something like

          (let ((coding-system-for-read 'binary))
            (read-event ...))

should give you what you want,


        Stefan

Re: read a reply from the terminal

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > I trying to do: (send-string-to-terminal "\e[>0c") and read the string
  > > that the terminal sends back.  Can this be done reliably in elisp?
  > 
  > Something like
  > 
  >           (let ((coding-system-for-read 'binary))
  >             (read-event ...))
  > 
  > should give you what you want,

Thanks, that seems to do it. 

Here's a patch. It works for me correctly for all the terminals that I
tried it on. 

Any objection to putting this in? 

*** xterm.el	13 Jun 2007 16:19:48 -0700	1.39
--- xterm.el	14 Jul 2007 17:06:05 -0700	
***************
*** 400,406 ****
      ;; Do it!
      (xterm-register-default-colors)
      ;; This recomputes all the default faces given the colors we've just set up.
!     (tty-set-up-initial-frame-faces)))
  
  ;; Set up colors, for those versions of xterm that support it.
  (defvar xterm-standard-colors
--- 400,436 ----
      ;; Do it!
      (xterm-register-default-colors)
      ;; This recomputes all the default faces given the colors we've just set up.
!     (tty-set-up-initial-frame-faces)
! 
!     ;; Try to turn on the modifyOtherKeys feature on modern xterms.
!     ;; When it is turned on much more key bindings work: things like
!     ;; C-. C-, etc.
!     ;; To do that we need to find out if the current terminal supports
!     ;; modifyOtherKeys. At this time only xterm does.
!     (let ((coding-system-for-read 'binary)
! 	  (chr nil)
! 	  (str nil))
!       ;; Try to find out the type of terminal by sending a "Secondary
!       ;; Device Attributes (DA)" query.
!       (send-string-to-terminal "\e[>0c")
! 
!       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
!       (when (equal (read-event) ?\e)
! 	(when (equal (read-event) 91)
! 	  (while (not (equal (setq chr (read-event)) ?c))
! 	    (setq str (concat str (string chr))))
! 	  (when (string-match ">[0-9]+;\\([0-9]+\\);[0-9]+" str)
! 	    ;; NUMBER2 is the xterm version number, look for something
! 	    ;; greater than 216, the version when modifyOtherKeys was
! 	    ;; introduced.
! 	    (when (>= (string-to-number 
! 		       (substring str (match-beginning 1) (match-end 1))) 216)
! 	      ;; Make sure that the modifyOtherKeys state is restored when
! 	      ;; suspending, resuming and exiting.
! 	      (add-hook 'suspend-hook 'xterm-turn-off-modifyOtherKeys)
! 	      (add-hook 'suspend-resume-hook 'xterm-turn-on-modifyOtherKeys)
! 	      (add-hook 'kill-emacs-hook 'xterm-turn-off-modifyOtherKeys)
! 	      (xterm-turn-on-modifyOtherKeys))))))))
  
  ;; Set up colors, for those versions of xterm that support it.
  (defvar xterm-standard-colors
***************
*** 518,522 ****
--- 548,560 ----
      ;; right colors, so clear them.
      (clear-face-cache)))
  
+ (defun xterm-turn-on-modifyOtherKeys ()
+   "Turn on the modifyOtherKeys feature of xterm."
+   (send-string-to-terminal "\e[>4;1m"))
+ 
+ (defun xterm-turn-off-modifyOtherKeys ()
+   "Turn off the modifyOtherKeys feature of xterm."
+   (send-string-to-terminal "\e[>4m"))
+ 
  ;; arch-tag: 12e7ebdd-1e6c-4b25-b0f9-35ace25e855a
  ;;; xterm.el ends here

Re: read a reply from the terminal

[Stefan Monnier]

> ! 	(when (equal (read-event) 91)
                                  ^^
                                  ?\[

-- Stefan

Re: read a reply from the terminal

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> !       ;; Try to find out the type of terminal by sending a "Secondary
> !       ;; Device Attributes (DA)" query.
> !       (send-string-to-terminal "\e[>0c")
> ! 
> !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
> !       (when (equal (read-event) ?\e)

> ! 	(when (equal (read-event) 91)
> ! 	  (while (not (equal (setq chr (read-event)) ?c))
> ! 	    (setq str (concat str (string chr))))

What if the terminal is ignoring the query, or there is some other
communication problem, wouldn't that mean that read-event would hang
here?  IMHO the calls should use the timeout feature.

Andreas.

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

Re: read a reply from the terminal

[Dan Nicolaescu]

Andreas Schwab <schwab@suse.de> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > !       ;; Try to find out the type of terminal by sending a "Secondary
  > > !       ;; Device Attributes (DA)" query.
  > > !       (send-string-to-terminal "\e[>0c")
  > > ! 
  > > !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
  > > !       (when (equal (read-event) ?\e)
  > 
  > > ! 	(when (equal (read-event) 91)
  > > ! 	  (while (not (equal (setq chr (read-event)) ?c))
  > > ! 	    (setq str (concat str (string chr))))
  > 
  > What if the terminal is ignoring the query, or there is some other
  > communication problem, wouldn't that mean that read-event would hang
  > here?  IMHO the calls should use the timeout feature.

Good point. What is a good value for the timeout? 

Re: read a reply from the terminal

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sun, 15 Jul 2007 08:30:00 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Andreas Schwab <schwab@suse.de> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > !       ;; Try to find out the type of terminal by sending a "Secondary
>   > > !       ;; Device Attributes (DA)" query.
>   > > !       (send-string-to-terminal "\e[>0c")
>   > > ! 
>   > > !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
>   > > !       (when (equal (read-event) ?\e)
>   > 
>   > > ! 	(when (equal (read-event) 91)
>   > > ! 	  (while (not (equal (setq chr (read-event)) ?c))
>   > > ! 	    (setq str (concat str (string chr))))
>   > 
>   > What if the terminal is ignoring the query, or there is some other
>   > communication problem, wouldn't that mean that read-event would hang
>   > here?  IMHO the calls should use the timeout feature.
> 
> Good point.

I thought about the same problem as Andreas, but didn't ask the
question since you told that you've tested the code on many terminals,
and I assumed those terminals included at least one that didn't
support this command.  If that's not so, I suggest to test the new
code (with timeout) on such a terminal, as well as on those which do
support the command.

Re: read a reply from the terminal

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Sun, 15 Jul 2007 08:30:00 -0700
  > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
  > > 
  > > Andreas Schwab <schwab@suse.de> writes:
  > > 
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > !       ;; Try to find out the type of terminal by sending a "Secondary
  > >   > > !       ;; Device Attributes (DA)" query.
  > >   > > !       (send-string-to-terminal "\e[>0c")
  > >   > > ! 
  > >   > > !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
  > >   > > !       (when (equal (read-event) ?\e)
  > >   > 
  > >   > > ! 	(when (equal (read-event) 91)
  > >   > > ! 	  (while (not (equal (setq chr (read-event)) ?c))
  > >   > > ! 	    (setq str (concat str (string chr))))
  > >   > 
  > >   > What if the terminal is ignoring the query, or there is some other
  > >   > communication problem, wouldn't that mean that read-event would hang
  > >   > here?  IMHO the calls should use the timeout feature.
  > > 
  > > Good point.
  > 
  > I thought about the same problem as Andreas, but didn't ask the
  > question since you told that you've tested the code on many terminals,
  > and I assumed those terminals included at least one that didn't
  > support this command.  If that's not so, I suggest to test the new
  > code (with timeout) on such a terminal, as well as on those which do
  > support the command.

I have now tested the code using a timeout of 0.1 on xterm, rxvt,
gnome-terminal, konsole, putty, and a very old xterm (from an old
Solaris). It works fine for all of them. All these terminals support
the "\e[>0c" query. 
I also tested it on a Linux console, that does not support the query.

It works fine everywhere. 

Re: read a reply from the terminal

[Davis Herring]

> I have now tested the code using a timeout of 0.1 on xterm, rxvt,
> gnome-terminal, konsole, putty, and a very old xterm (from an old
> Solaris). It works fine for all of them. All these terminals support
> the "\e[>0c" query.
> I also tested it on a Linux console, that does not support the query.

Sorry to bring this up so much later, but is a timeout of 0.1 always
appropriate?  Is there ever a circumstance where a remote host would need
to provide the information, or is it always trapped by a local terminal
driver in such a case?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: read a reply from the terminal

[Dan Nicolaescu]

"Davis Herring" <herring@lanl.gov> writes:

  > > I have now tested the code using a timeout of 0.1 on xterm, rxvt,
  > > gnome-terminal, konsole, putty, and a very old xterm (from an old
  > > Solaris). It works fine for all of them. All these terminals support
  > > the "\e[>0c" query.
  > > I also tested it on a Linux console, that does not support the query.
  > 
  > Sorry to bring this up so much later, but is a timeout of 0.1 always
  > appropriate?  Is there ever a circumstance where a remote host would need
  > to provide the information, or is it always trapped by a local terminal
  > driver in such a case?

The terminal emulator replies.

Re: read a reply from the terminal

[Stefan Monnier]

>> > I have now tested the code using a timeout of 0.1 on xterm, rxvt,
>> > gnome-terminal, konsole, putty, and a very old xterm (from an old
>> > Solaris). It works fine for all of them. All these terminals support
>> > the "\e[>0c" query.
>> > I also tested it on a Linux console, that does not support the query.
>> 
>> Sorry to bring this up so much later, but is a timeout of 0.1 always
>> appropriate?  Is there ever a circumstance where a remote host would need
>> to provide the information, or is it always trapped by a local terminal
>> driver in such a case?

> The terminal emulator replies.

But if you're running Emacs remotely via an ssh shell, then there's
a network between Emacs and the terminal emulator.  E.g. in the case of
PuTTY, or in my case (xterm -e ssh <host>).


        Stefan

Re: read a reply from the terminal

[Richard Stallman]

    !       ;; Try to find out the type of terminal by sending a "Secondary
    !       ;; Device Attributes (DA)" query.
    !       (send-string-to-terminal "\e[>0c")
    ! 
    !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
    !       (when (equal (read-event) ?\e)
    ! 	(when (equal (read-event) 91)

Is there any danger that some terminal programs won't implement
that query, and that these read-event calls will hang?

Perhaps the best thing to do is install the patch
and see if anyone complains.

    + (defun xterm-turn-on-modifyOtherKeys ()

Please rename that to xterm-turn-on-modify-other-keys.
Likewise the following function.

Re: read a reply from the terminal

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     !       ;; Try to find out the type of terminal by sending a "Secondary
  >     !       ;; Device Attributes (DA)" query.
  >     !       (send-string-to-terminal "\e[>0c")
  >     ! 
  >     !       ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c
  >     !       (when (equal (read-event) ?\e)
  >     ! 	(when (equal (read-event) 91)
  > 
  > Is there any danger that some terminal programs won't implement
  > that query, and that these read-event calls will hang?

It's not impossible, someone can implement a terminal emulator that
does not support this type of query and still set TERM to xterm. Most
applications won't care.. To be safe adding a timeout to the
read-event call seems to be the right thing to do.

  > Perhaps the best thing to do is install the patch
  > and see if anyone complains.

I'll do that.

  >     + (defun xterm-turn-on-modifyOtherKeys ()
  > 
  > Please rename that to xterm-turn-on-modify-other-keys.
  > Likewise the following function.

Sure.

Re: read a reply from the terminal

[Johan Bockgård]

Is there a way to make Emacs always interpret ^G as a normal
character?

Here's an illustration of the problem:

    emacs -nw -Q

In *scratch*, press C-j after

     (read-key-sequence "Paste: ")

Assuming that the X selection contains the characters `a b c ^G 1 2
3', a <middle-click> produces

    "^G"
    123

"abc" are lost.

(The same thing happens with responses to send-string-to-terminal.)

Re: read a reply from the terminal

[Eli Zaretskii]

> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
> Date: Sun, 15 Jul 2007 00:16:00 +0200
> 
> 
> Is there a way to make Emacs always interpret ^G as a normal
> character?

Does it help to use set-input-mode?

Re: read a reply from the terminal

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: bojohan+news@dd.chalmers.se (Johan =?utf-8?Q?Bockg=C3=A5rd?=)
>> Date: Sun, 15 Jul 2007 00:16:00 +0200
>> 
>> 
>> Is there a way to make Emacs always interpret ^G as a normal
>> character?
>
> Does it help to use set-input-mode?

Yes. Thanks a lot.

-- 
Johan Bockgård