;;; -*- Mode:LISP; Package:USER; Base:10 -*-
;
;In System 102.92, Local-File 56.0, FILE-Server 13.1, Unix-Interface 5.3,
;MagTape 40.14, ZMail 57.1, Tiger 20.4, KERMIT 26.4,
;MEDIUM-RESOLUTION-COLOR 17.3, Experimental MCC 3.7, microcode 753,
; Release 2.0 - MCC Site (New Host Tables), on John's Hansel:

;; Debbie (or any LMI personnel):

;; This code will DEFINITELY reproduce the problem I'm encountering with READ-DELIMITED-STRING (which I think
;; is actually a bug with the rubout-handler.)

;;; -*- Mode:LISP; Package:USER -*-
(DEFFLAVOR TRASH
	   ()
	   (TV:WINDOW)
  :SETTABLE-INSTANCE-VARIABLES)

(DEFMETHOD (TRASH :READ-INPUT) (&OPTIONAL (INPUT-STRING ""))
  "Read input from the io-buffer using read-delimited-string."
  (READ-DELIMITED-STRING '(#/RETURN #/END) SELF NIL
			 (LIST '(:PREEMPTABLE NIL)
			       (LIST ':INITIAL-INPUT INPUT-STRING)
			       (LIST ':INITIAL-INPUT-INDEX (STRING-LENGTH INPUT-STRING)))))

;; After compiling this code, get into a listener and type:

(setq x (make-instance 'trash :edges-from ':mouse))

;; at this point, x has been created, and the following line should be entered:

(progn (send x :select)(send x :read-input))

;; This selects x, and starts the :READ-INPUT method (which actually invokes the rubout-handler).
;; Now, type the following string:  "hello my name is".  You'll see it echo in the window
;; referenced by x.  Now move the mouse over this window, and hit the middle mouse button.
;; Notice that the above s-expression beginning with progn returned some indication of a mouse-button
;; having been pressed.  Notice also that the input remains on the screen (which is wrong!, because if
;; you re-invoke the :READ-INPUT method, the input will re-echo...BAD!).  Now to see if there is anything
;; in the buffer type:

(send x :io-buffer)

;; THis returns the descriptor of the io-buffer (struct)...notice that it says "empty".
;; To further 'verify' this, type:

(send x :any-tyi-no-hang)

;; This returns nil.  Now type:

(send x :listen)

;; Curiously, this returns t.  Now type:

(string (send x :tyi))

;; This returns "h", which was the first character we typed above (remember, "hello my name is").
;; Now, type:

(send x :untyi (send x :tyi))

;; This oddly bombs saying that we tried to 'untyi' something different than the last character gotten
;; from the io-buffer (which you would think was the character gotten from the 'tyi', but NOOOOOO!)
;; Notice that if you re-invoke the :READ-INPUT method, that all characters appear in the input stream;
;; thus, READ-DELIMITED-STRING knows where it stuffed the characters (after it was preempted by the
;; mouse-click.)  However, not all functions know to look in this buffer.  The :TYI and :ANY-TYI methods
;; find characters, as does :LISTEN,
;; but  neither :ANY-TYI-NO-HANG nor :UNTYI seem to look at the same buffer(s) as the aforementioned
;; methods (obviated by the fact that they do not find any characters).  This is, in a word, WEIRD
;; (as well as WRONG!)

;; I hope with this code you can track down this bug...needless to say it's VERY difficult to program
;; around (KLUDGE!) around this bug.  Please advise me of the status as soon as you receive and reproduce
;; this bug.

;; Thanks for your time...happy bug-fixing.

;; John W. Hardin
;; MCC
;; (512) 834-3535