[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

inferior-lisp-mode, no communication with lisp process

From: Jan Eppo Jonker
Subject: inferior-lisp-mode, no communication with lisp process
Date: Thu, 24 Jan 2002 17:27:47 +0100 (CET)

This bug report will be sent to the Free Software Foundation,
 not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

In GNU Emacs 20.7.1 (i386-suse-linux, X toolkit)
 of Tue May 15 2001 on ivy
configured using `configure  --with-gcc --with-pop --with-system-malloc 
--prefix=/usr --exec-prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --sharedstatedir=/var/state --libexecdir=/usr/lib 
--with-x --with-x-toolkit=lucid --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib i386-suse-linux'

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The actions that trigger the bug are

Start in a buffer "LispSource". Then:

- (maybe load library inf-lisp: M-x load-library   inf-lisp
- start inferior-lisp-mode:     M-x inferior-lisp-mode
- start lisp process:           M-x 1 M-x inferior-lisp <whatever lisp you have,
                                it might even be `cat', as long as it reads 
                                and writes stdout.
This leaves you in a new buffer "*inferior-lisp*" with a running process.  (see

-switch back to buffer LispSource: C-x b RET

This leaves you in buffer LispSource, with no process attached, according to the

According to C-h v :i nferior-lisp-buffer's value is "*inferior-lisp*"

Now for the bug:
=================================  BUG ========================================

Pressing C-c C-e ( bound to \\[lisp-eval-defun] ) near a Lisp expression leads
to no response at all.


According to the documentation of inferior-lisp-buffer however,
the lisp expression should have been sent to the lisp process:

------------------------------ Documentation ---------------------------------
If you do a \\[lisp-eval-defun] command on some Lisp source code,
what process do you send it to?

- If you're in a process buffer (foo, bar, or *inferior-lisp*),
  you send it to that process.
- If you're in some other buffer (e.g., a source file), you
  send it to the process attached to buffer `inferior-lisp-buffer'.
This process selection is performed by function `inferior-lisp-proc'.

So it turns out that the following implementation of `inferior-lisp-proc' in
inf-lisp.el is erroneous:

*******************************  BUG 

;;  "Returns the current inferior Lisp process.
;; See variable `inferior-lisp-buffer'."
(defun inferior-lisp-proc ()
  (let ((proc (get-buffer-process (if (eq major-mode 'inferior-lisp-mode)
    (or proc
        (error "No Lisp subprocess; see variable `inferior-lisp-buffer'"))))


And yes, there is a suspicious test on the major MODE of the current buffer
being `inferior-lisp-mode. That is probably but not necessarily so.
So the return value will often be (current-buffer), i.e. the lisp source 
buffer, with
no process attached.
According to the documentation, the mode is not relevant.
What IS relevant is, whether a process is attached.

This implementation occurs already in version 19.34b

In my opinion, the implementation should be something like:

+++++++++++++++++++++++++++++++ Proposed FIX 

(defun inferior-lisp-proc ()
  (let ((procb (get-buffer-process (current-buffer))))
    (or procb
        (let ((procp (get-buffer-process inferior-lisp-buffer)))
          (or procp
              (error  "No Lisp subprocess; see variable 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]