Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!SUN.COM!peck
From: peck@SUN.COM
Newsgroups: gnu.emacs.bug
Subject: Re: Emacstool and numbers when clicking mouse & patch
Message-ID: <8811021940.AA15706@denali.sun.com>
Date: 2 Nov 88 19:40:55 GMT
References: <26416@tut.cis.ohio-state.edu>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 123

Here's the scoop:
  Emacstool merely arranges for function keys and mouse clicks to
be encoded as ascii character strings and sent to its subordinate process.
The subordinate process is generally GNU Emacs.
  What Emacs does with those strings is out of the control of Emacstool.

  Generally, Emacs should be seeing a terminal type of "sun" and therefore
it will load .../lisp/term/sun.elc  which binds useful functions to the
keysequences that Emacstool is sending.  If sun.elc is not loaded for any
reason [two reasons i've seen: term type not "sun", lib path incorrect]
then the keys will be unbound and you will get:
  1. unbound-key for ^x*
  2. self-insert of "(<button> <x> <y> <delta-time>)"
Ususally ^x* gets bound to sun-mouse-handler which reads the list of 
numbers to determine where the mouse hit occurs, and then dispatch to
the appropriate function in the mouse binding map.

The function keys send ^x@<char-number><c-m-shift-keybank>
and the suntool-map is setup to decode these and call appropriate functions.
If sun.elc is not loaded this will also get "unbound-key" and then
insert the two selection characters.


Unfortunately, Emacstool does not go out of its way to set the 
terminal-type of the window it creates, so it may inherit some other type.

Here is a patch for the bug: (I have not verified, let me know if it works)

Date: Wed, 17 Aug 88 16:11:51 PDT
From: cohesive!kla!serendip!pml@sun.com (PM Lashley)
Message-Id: <8808172311.AA09798@serendip.kla.com>
To: info-gnu-emacs@prep.ai.mit.edu
Subject: emacstool fix
X-Disclaimer: Standard

Emacstool as distributed in release 18.49 does not ensure that the TERM and
TERMCAP environment variables accurately reflect the terminal emulation
performed by it's TTY subwindow.  This is not noticable under the normal
circumstance where emacstool is envoked from a shelltool, from cmdtool or
via .sunview <.suntools>.  However, should you be emulating a different
type of terminal....

Note that equivalent fixes would apply to any SunView tool which envokes
a screen-oriented program in a TTY subwindow.

The following patch makes the pnambc assumption that the appropriate termcap
entry for a TTY subwindow is `sun'.

(I have been off the net for a while.  I do not yet have the 18.50 or 18.51
patches.  If this has been fixed in either of them, I apologise for wasting
everyone's time, and network bandwidth.)


*** emacstool.dist-18.49	Wed Jul 20 18:58:24 1988
--- emacstool.c	Wed Aug 17 15:43:24 1988
***************
*** 244,249 ****
--- 244,251 ----
       char **argv;
  {
    int error_code;	/* Error codes */
+   char	*scratchString ;	/* Current TERMCAP value */
+   
    if(getenv("DEBUGEMACSTOOL"))
      console = fdopen (console_fd = open("/dev/console",O_WRONLY), "w");
  
***************
*** 252,257 ****
--- 254,292 ----
  			    ICON_IMAGE, &icon_image,
  			    0);
  
+   /*
+    * Set the TERM environment variable to match the terminal emulation
+    * provided by the TTY subwindow (just in case it was not a shelltool <sun>
+    * or cmdtool <sun-cmd> window).  This should not be a hard-coded,
+    * pnambc value, but there is currently no way to dynamically determine
+    * what the correct termcap/terminfo entry for a TTY subwindow is...
+    */
+   scratchString = (char*)getenv("TERM") ;
+   if  (( ! scratchString) || (strcmp(scratchString, "sun") != 0))
+     {
+       if  (putenv("TERM=sun") != 0)
+ 	{
+ 	  fprintf (stderr, "%s: Could not set TERM=sun, using `%s'\n",
+ 		   argv[0],
+ 		   (char *)getenv("TERM")) ;
+ 	} ;
+ 
+       /*
+        * If TERMCAP starts with a slash, it is the pathname of the
+        * termcap file, not an entry extracted from it....
+        * If there is no TERMCAP environment variable, don't worry about it.
+        */
+       scratchString = (char *)getenv("TERMCAP") ;
+       if  (scratchString && (*scratchString != '/'))
+ 	{
+ 	  if  (putenv("TERMCAP=") != 0)
+ 	    {
+ 	      fprintf (stderr, "%s: Could not clear TERMCAP\n", argv[0]) ;
+ 	    } ;
+ 	} ;
+     } ;
+   
+   /* Create a tty with emacs in it */
    if (!(argv[0] = (char *)getenv("EMACSTOOL")))	/* Set emacs command name */
        argv[0] = emacs_name;			
    for (argc = 1; argv[argc]; argc++)		/* Use last one on line */
***************
*** 276,282 ****
  			 FRAME_ARGC_PTR_ARGV, &argc, argv,
  			 0);
  
-   /* Create a tty with emacs in it */
    ttysw = window_create (frame, TTY, 
  			 TTY_QUIT_ON_CHILD_DEATH, TRUE, 
  			 TTY_BOLDSTYLE, 8, 
--- 311,316 ----

PMLashley	sun!cohesive!kla!pat
KLA Instruments	POBox 5016, 3901 Burton Drive
		Santa Clara, CA 95052
		408/988-6100