I was asked something in a *compilation* window

I was asked something in a *compilation* window

[Dan Jacobson]

What happens when we do M-x compile and something asks us a question
right there in the compile window?  No, echo y > /dev/pts/4 doesn't
work.  Maybe one has to echo to /proc/... . Anyway, the user can't
talk back thru the terminal glass... there should be a way made
possible just in case.  I mean otherwise all you can do is start the
job over [not always an option].

No, I didn't expect it to ask me but it is, now what?
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: I was asked something in a *compilation* window

[Kai Großjohann]

jidanni@deadspam.com (Dan Jacobson) writes:

> What happens when we do M-x compile and something asks us a question
> right there in the compile window?

In principle, process-send-string should work.

Doing it right is on my todo list.  But don't hold your breath.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: I was asked something in a *compilation* window

[Kevin Rodgers]

Kai Großjohann wrote:

> jidanni@deadspam.com (Dan Jacobson) writes:
> 
> 
>>What happens when we do M-x compile and something asks us a question
>>right there in the compile window?
>>
> 
> In principle, process-send-string should work.
> 
> Doing it right is on my todo list.  But don't hold your breath.

I wrote a small patch to compile.el (compile-internal) and a very small
add-on (compile-input.el) way back in October, 1996 for Karl Berry to
enable user input in *compile* buffers.  I'll post it again if anyone's
interested.

-- 
Kevin Rodgers <kevinr@ihs.com>

breakthrough: I was asked something in a *compilation* window

[Dan Jacobson]

Amazing breakthrough in the realm of commands to provide the user: a
way for him to talk back when a *compilation* comes to a screeching
halt an asks the user a question thru the impenetrable one way glass...

Sure you lisp programmers do this all the time but us "M-x blabla"
users haven't had a tool...

>>>>> "T" == Thien-Thi Nguyen <ttn@glug.org> writes:

T> i bind ":" to the following:

T> (defun compilation-send-line (line)
T>   (interactive "sLine: ")
T>   (process-send-string (buffer-name) (concat line "\n")))

T> when prompted, i type something like `: y RET'.

This seems to be an amazing breakthrough.   With a little polish this
should be an immediate candidate for  inclusion into the next emacs
[and M-x compile documentation.]

notes on usage: one should do
(setq compilation-scroll-output t)

By the way, emacs bug: in a *compilation* window do C-h m, gee, sure
looks puny these days.  Where's all the special bindings?
Also the user will never learn about e.g. compilation-scroll-output
from there or C-h f compile.
-- 
http://jidanni.org/ Taiwan(04)25854780

Re: I was asked something in a *compilation* window

[Francesco Potorti`]

kevinr@ihs.com (Kevin Rodgers) writes:
   I wrote a small patch to compile.el (compile-internal) and a very small
   add-on (compile-input.el) way back in October, 1996 for Karl Berry to
   enable user input in *compile* buffers.  I'll post it again if anyone's
   interested.
   
I think that would be a useful addition to Emacs.

Re: I was asked something in a *compilation* window

[Kevin Rodgers]

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

Francesco Potorti` wrote:

> kevinr@ihs.com (Kevin Rodgers) writes:
>    I wrote a small patch to compile.el (compile-internal) and a very small
>    add-on (compile-input.el) way back in October, 1996 for Karl Berry to
>    enable user input in *compile* buffers.  I'll post it again if anyone's
>    interested.
>    
> I think that would be a useful addition to Emacs.


OK, here's what we came up with back then.


-- 
Kevin Rodgers <kevinr@ihs.com>

[-- Attachment #2: compile.el-compile-disable-input.patch --]
[-- Type: text/plain, Size: 3389 bytes --]

From kevinr@airedale Fri Oct 18 07:50:16 1996
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "October" "1996" "07:50:11" "-0600" "Kevin Rodgers" "kevinr@airedale" nil nil "Re: standard input in *compile* buffers" "^From:" nil nil "10" nil "standard input in *compile* buffers" nil nil nil]
	nil)
Return-Path: <kevinr@airedale>
Received: from ihs.com by airedale.ihsyp (SMI-8.6/SMI-SVR4)
	id HAA03501; Fri, 18 Oct 1996 07:50:15 -0600
Received: from airedale.ihsyp (airedale.ihs.com) by ihs.com (4.1/SMI-4.1)
	id AA02413; Fri, 18 Oct 96 07:50:04 MDT
Received: by airedale.ihsyp (SMI-8.6/SMI-SVR4)
	id HAA03498; Fri, 18 Oct 1996 07:50:11 -0600
Message-Id: <199610181350.HAA03498@airedale.ihsyp>
Reply-To: kevin.rodgers@ihs.com
X-Newsreader: TIN [version 1.2 PL2]
Content-Length: 2296
From: kevinr@airedale (Kevin Rodgers)
Organization: IHS Electronic Systems Development
To: GNU Emacs bug reports <bug-gnu-emacs@prep.ai.mit.edu>
Cc: kb@cs.umb.edu (K. Berry)
Subject: Re: standard input in *compile* buffers
Newsgroups: gnu.emacs.bug
Date: Fri, 18 Oct 1996 07:50:11 -0600

In article <199610122106.AA05911@terminus.cs.umb.edu> kb@cs.umb.edu (K. Berry) wrote:
>Since it's not possible to actually type input in *compile* buffers,
>could input be redirected from /dev/null so programs aren't fooled?
>Naturally, it would be even nicer to actually be able to interact in the
>buffer.  In that case, the redirection could be optional.

Here's a slightly improved version of the patch I submitted, which makes
the redirection optional (controlled by the new variable compile-
disable-input) as Karl suggested.  Its default value makes compile
behave the same whether the platform supports asynchronous processes or
not.

With my first patch, I had wondered whether `process-send-eof' should
not be called until after the compilation process' sentinel, filter, and
marker were set; but it seems to work fine just as it is.


Fri Oct 18 07:29:27 1996  Kevin Rodgers  <kevinr@ihs.com>

	* compile.el (compile-disable-input): Define.
	(compile-internal): If compile-disable-input is non-nil, send an
	EOF to the compilation process.


*** lisp/compile.el.orig	Fri Apr 26 13:44:02 1996
--- lisp/compile.el	Thu Oct 17 13:50:32 1996
***************
*** 358,363 ****
--- 358,369 ----
  			(cons msg code)))
  	       (cons msg code)))))))
  
+ (defvar compile-disable-input t
+   "*If non-nil, redirect input for compilation processes from `/dev/null'.
+ 
+ This only affects platforms that support asynchronous processes (see
+ start-process); synchronous compilation processes never accept input.")
+ 
  (defun compile-internal (command error-message
  				 &optional name-of-mode parser regexp-alist
  				 name-function)
***************
*** 445,450 ****
--- 451,458 ----
  		   (proc (start-process-shell-command (downcase mode-name)
  						      outbuf
  						      command)))
+ 	      (if compile-disable-input
+ 		  (process-send-eof proc))
  	      (set-process-sentinel proc 'compilation-sentinel)
  	      (set-process-filter proc 'compilation-filter)
  	      (set-marker (process-mark proc) (point) outbuf)
-- 
Kevin Rodgers <kevin.rodgers@ihs.com>   Project Engineer
Information Handling Services           Electronic Systems Development
15 Inverness Way East, M/S A201         GO BUFFS!
Englewood CO 80112-5776 USA             1+ (303) 397-2807[voice]/754-3975[fax]


[-- Attachment #3: compile-input.el --]
[-- Type: text/plain, Size: 3089 bytes --]

From kevinr@airedale Fri Oct 18 07:55:21 1996
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "October" "1996" "07:55:17" "-0600" "Kevin Rodgers" "kevinr@airedale" nil nil "Re: standard input in *compile* buffers" "^From:" nil nil "10" nil "standard input in *compile* buffers" nil nil nil]
	nil)
Return-Path: <kevinr@airedale>
Received: from ihs.com by airedale.ihsyp (SMI-8.6/SMI-SVR4)
	id HAA03512; Fri, 18 Oct 1996 07:55:20 -0600
Received: from airedale.ihsyp (airedale.ihs.com) by ihs.com (4.1/SMI-4.1)
	id AA02584; Fri, 18 Oct 96 07:55:09 MDT
Received: by airedale.ihsyp (SMI-8.6/SMI-SVR4)
	id HAA03509; Fri, 18 Oct 1996 07:55:17 -0600
Message-Id: <199610181355.HAA03509@airedale.ihsyp>
In-Reply-To: <199610181350.HAA03498@airedale.ihsyp>
References: <199610181350.HAA03498@airedale.ihsyp>
Reply-To: kevin.rodgers@ihs.com
X-Mailer: VM 5.96 (beta)
Content-Length: 1835
From: kevinr@airedale (Kevin Rodgers)
X-Organization: IHS Electronic Systems Development
To: GNU Emacs bug reports <bug-gnu-emacs@prep.ai.mit.edu>,
        GNU Emacs source code <gnu-emacs-sources@prep.ai.mit.edu>
Cc: kb@cs.umb.edu (K. Berry)
Subject: Re: standard input in *compile* buffers
Newsgroups: gnu.emacs.bug
Date: Fri, 18 Oct 1996 07:55:17 -0600

I wrote [in gnu.emacs.bug]:
>Here's a slightly improved version of the patch I submitted, which makes
>the redirection optional (controlled by the new variable compile-
>disable-input) as Karl suggested.

And here's a slightly improved version of compile-input.el, which unsets
compile-disable-input:

;;; compile-input.el

(defun compile-enable-input ()
  "Enable user input to *compilation* buffers.
To do so, add this function to compilation-mode-hook."
  ;; Emulate comint-mode:
  (require 'comint)
  (set (make-local-variable 'comint-input-ring)
       (make-ring comint-input-ring-size))
  (set (make-local-variable 'comint-last-input-start)
       (make-marker))
  (set-marker comint-last-input-start (point-min))
  (set (make-local-variable 'comint-last-input-end)
       (make-marker))
  (set-marker comint-last-input-end (point-min))
  (set (make-local-variable 'comint-last-output-start)
       (make-marker))
  (set-marker comint-last-output-start (point-max))
  (add-hook (make-local-variable 'pre-command-hook)
	    'comint-preinput-scroll-to-bottom)
  ;; Move point to EOB on input:
  (set (make-local-variable 'comint-scroll-to-bottom-on-input)
       'this)
  ;; Restore useful bindings for input:
  (local-unset-key " ")			; scroll-up
  (local-unset-key "\^?")		; scroll-down
  ;; Add bindings to send input to compilation process:
  (local-set-key "\C-c\C-d" 'comint-send-eof)
  (local-set-key "\C-m" 'comint-send-input)
  ;; Enable input:
  (set (make-local-variable 'compile-disable-input) nil))

(add-hook 'compilation-mode-hook 'compile-enable-input)
-- 
Kevin Rodgers <kevin.rodgers@ihs.com>   Project Engineer
Information Handling Services           Electronic Systems Development
15 Inverness Way East, M/S A201         GO BUFFS!
Englewood CO 80112-5776 USA             1+ (303) 397-2807[voice]/754-3975[fax]