IELM prompt

IELM prompt

[Luc Teirlinck]

There are (at least) three problems with the ielm prompt:

1.  It is non-customizable.  _Even_ if one sets ielm-prompt outside of
    Custom, the :set-function gets called anyway when ielm.el is loaded
    and the prompt becomes read-only, overriding the user's attempt at
    customizing the read-only-ness away.  (This is because of
    custom-initialize-reset.)

2.  It is not _really_ read-only.  One can paste stuff inside the
    prompt.  The default prompt is "ELISP> ".  The last space is
    invisibly part of the read-only prompt.  I just keep pasting stuff
    accidentally into that last space.  The pasted forms to be
    executed are then invisibly part of the read-only prompt with
    extremely confusing results.  This is very annoying.

3.  Flushing the output with C-c C-o produces an error instead of the
    intended "*** output flushed ***" message.  This is bad, because
    one likes to have a record of the fact that (probably extensive)
    output was flushed.

Below are a patch to ielm.el, eliminating problems (1) and (2) and a
(trivial) patch to comint.el eliminating (3).

The patch to comint.el binds inhibit-read-only to t in
comint-delete-output.  To me, that makes sense regardless of the
problems with the ielm prompt.  If one wants the previous output gone,
one wants it gone regardless of whether part of that output has the
read-only property.

The patch to ielm.el, apart from solving (1) and (2), also gets rid of
the unnecessary :get and :set keywords in the ielm-prompt defcustom,
letting inferior-emacs-lisp-mode do the work instead.  Customizing
the prompt would, by default, no longer affect existing *ielm*
buffers.  I believe that is an improvement, because two distinct
prompts in the same ielm run looks messy.  (I often save *ielm* buffers.)

If there are no objections, I could install these patches:

===File ~/comint-diff=======================================
*** comint.el	14 Apr 2004 14:14:13 -0500	1.294
--- comint.el	22 Apr 2004 18:50:10 -0500	
***************
*** 2006,2012 ****
  Does not delete the prompt."
    (interactive)
    (let ((proc (get-buffer-process (current-buffer)))
! 	(replacement nil))
      (save-excursion
        (let ((pmark (progn (goto-char (process-mark proc))
  			  (forward-line 0)
--- 2006,2013 ----
  Does not delete the prompt."
    (interactive)
    (let ((proc (get-buffer-process (current-buffer)))
! 	(replacement nil)
! 	(inhibit-read-only t))
      (save-excursion
        (let ((pmark (progn (goto-char (process-mark proc))
  			  (forward-line 0)
============================================================

===File ~/ielm-diff=========================================
*** ielm.el	22 Apr 2004 08:56:46 -0500	1.36
--- ielm.el	22 Apr 2004 20:47:27 -0500	
***************
*** 49,60 ****
    :type 'boolean
    :group 'ielm)
  
  (defcustom ielm-prompt "ELISP> "
!   "Prompt used in IELM."
    :type 'string
!   :group 'ielm
!   :get #'(lambda (symbol) (substring-no-properties (symbol-value symbol)))
!   :set #'(lambda (symbol value) (set symbol (propertize value 'read-only t 'rear-nonsticky t))))
  
  (defcustom ielm-dynamic-return t
    "*Controls whether \\<ielm-map>\\[ielm-return] has intelligent behaviour in IELM.
--- 49,80 ----
    :type 'boolean
    :group 'ielm)
  
+ (defcustom ielm-prompt-read-only t
+   "If non-nil, the IELM prompt is read only.
+ \\<ielm-map>\
+ Setting this variable does not affect existing IELM runs, unless
+ you execute the command \\[inferior-emacs-lisp-mode] \(_not_ just
+ \\[ielm]) in that IELM buffer.  Even then, it does not affect
+ existing prompts.
+ 
+ You can give the IELM prompt more highly customized read-only
+ type properties \(for instance make only part of the prompt
+ read-only), by setting this option to nil, and then setting
+ `ielm-prompt', outside of Custom, to a string with the desired
+ text properties."
+   :type 'boolean
+   :group 'ielm
+   :version "21.4")
+ 
  (defcustom ielm-prompt "ELISP> "
!   "Prompt used in IELM.
! \\<ielm-map>\
! Setting this variable does not affect existing IELM runs, unless
! you execute the command \\[inferior-emacs-lisp-mode] \(_not_ just
! \\[ielm]) in that IELM buffer.  Even then, it does not affect
! existing prompts."
    :type 'string
!   :group 'ielm)
  
  (defcustom ielm-dynamic-return t
    "*Controls whether \\<ielm-map>\\[ielm-return] has intelligent behaviour in IELM.
***************
*** 429,434 ****
--- 449,456 ----
  The behaviour of IELM may be customised with the following variables:
  * To stop beeping on error, set `ielm-noisy' to nil
  * If you don't like the prompt, you can change it by setting `ielm-prompt'.
+ * If you do not like that the prompt is (by default) read-only, set
+   `ielm-prompt-read-only' to nil.
  * Set `ielm-dynamic-return' to nil for bindings like `lisp-interaction-mode'
  * Entry to this mode runs `comint-mode-hook' and `ielm-mode-hook'
   (in that order).
***************
*** 443,448 ****
--- 465,477 ----
    (setq comint-input-sender 'ielm-input-sender)
    (setq comint-process-echoes nil)
    (make-local-variable 'comint-dynamic-complete-functions)
+   (set (make-local-variable 'ielm-prompt)
+        (if ielm-prompt-read-only
+ 	   (propertize ielm-prompt
+ 		       'read-only t
+ 		       'rear-nonsticky t
+ 		       'front-sticky '(read-only))
+ 	 ielm-prompt))
    (setq comint-dynamic-complete-functions
  	'(ielm-tab comint-replace-by-expanded-history ielm-complete-filename ielm-complete-symbol))
    (setq comint-get-old-input 'ielm-get-old-input)
============================================================

Re: IELM prompt

[Luc Teirlinck]

>From my previous message:

   There are (at least) three problems with the ielm prompt:

   1.  It is non-customizable.

I meant:

There are (at least) three problems with the read-only-ness of the
ielm prompt:

1.  It is non-customizable.

Re: IELM prompt

[Luc Teirlinck]

>From my previous message:

   Customizing the prompt would, by default, no longer affect existing
   *ielm* buffers.  I believe that is an improvement, because two
   distinct prompts in the same ielm run looks messy.  (I often save
   *ielm* buffers.)

Actually, changing the prompt of an existing *ielm* buffer has much
worse consequences than just looking bad.  The old prompts will
confuse ielm and comint commands looking for prompts (which probably
means the majority of ielm and comint commands).  For instance, RET
and C-c RET on old prompts no longer work.  So excluding (by default)
existing *ielm* buffers from the new prompt definitely seems to be an
improvement.

Sincerely,

Luc.

Re: IELM prompt

[Juanma Barranquero]

On Thu, 22 Apr 2004 21:09:28 -0500 (CDT)
Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> There are (at least) three problems with the ielm prompt:

I originally put the read-onliness on the IELM prompt, but your patch is
a real improvement over what I did.

Another thing I'd like to do in IELM is showing the buffer on the
modeline, like:

  "(IELM:.emacs.el)"

instead of

  "(IELM:run)"

I think some people may prefer the ":run" thing because it is an
inferior process after all, but I really don't think it provides any
kind of useful information and it's just wasting "modeline real state" ;)

In the following patch I implement that by installing an :eval on
mode-line-process (so it works with C-c C-b and also when doing a
set-buffer on the prompt).  Of course, ielm-print-working-buffer becomes
irrelevant and I've deleted it.

What do you think?

                                                                Juanma



--- ielm.el.luc	2004-04-23 11:05:01.000000000 +0200
+++ ielm.el	2004-04-23 13:08:05.000000000 +0200
@@ -162,6 +162,5 @@
   ;; Some convenience bindings for setting the working buffer
   (define-key ielm-map "\C-c\C-b" 'ielm-change-working-buffer)
-  (define-key ielm-map "\C-c\C-f" 'ielm-display-working-buffer)
-  (define-key ielm-map "\C-c\C-v" 'ielm-print-working-buffer))
+  (define-key ielm-map "\C-c\C-f" 'ielm-display-working-buffer))
 
 (defvar ielm-font-lock-keywords
@@ -213,9 +212,4 @@
 ;;; Working buffer manipulation
 
-(defun ielm-print-working-buffer nil
-  "Print the current IELM working buffer's name in the echo area."
-  (interactive)
-  (message "The current working buffer is: %s" (buffer-name ielm-working-buffer)))
-
 (defun ielm-display-working-buffer nil
   "Display the current IELM working buffer.
@@ -223,6 +217,5 @@
 to its value of `window-point'!"
   (interactive)
-  (display-buffer ielm-working-buffer)
-  (ielm-print-working-buffer))
+  (display-buffer ielm-working-buffer))
 
 (defun ielm-change-working-buffer (buf)
@@ -232,6 +225,5 @@
 `set-buffer' at the IELM prompt."
   (interactive "bSet working buffer to: ")
-  (setq ielm-working-buffer (or (get-buffer buf) (error "No such buffer")))
-  (ielm-print-working-buffer))
+  (setq ielm-working-buffer (or (get-buffer buf) (error "No such buffer"))))
 
 ;;; Other bindings
@@ -435,6 +427,6 @@
 is preserved between successive evaluations.  In this way, expressions
 may be evaluated in a different buffer than the *ielm* buffer.
-Display the name of the working buffer with \\[ielm-print-working-buffer],
-or the buffer itself with \\[ielm-display-working-buffer].
+The name of the working buffer is always shown on the modeline;
+you can display the buffer itself with \\[ielm-display-working-buffer].
 
 During evaluations, the values of the variables `*', `**', and `***'
@@ -482,4 +474,5 @@
   (setq major-mode 'inferior-emacs-lisp-mode)
   (setq mode-name "IELM")
+  (setq mode-line-process '(":" (:eval (buffer-name ielm-working-buffer))))
   (use-local-map ielm-map)
   (set-syntax-table emacs-lisp-mode-syntax-table)

Re: IELM prompt

[Luc Teirlinck]

Juanma Barranquero wrote:

   I think some people may prefer the ":run" thing because it is an
   inferior process after all, but I really don't think it provides any
   kind of useful information and it's just wasting "modeline real state" ;)

It is not immediately that obvious.  The ":run" may not provide that
much information, but, on the other hand, it is not completely
redundant.  If you do C-c C-c or otherwise accidentally interrupt the
process, it changes to ":no process".

   In the following patch I implement that by installing an :eval on
   mode-line-process (so it works with C-c C-b and also when doing a
   set-buffer on the prompt).  Of course, ielm-print-working-buffer becomes
   irrelevant and I've deleted it.

The last statement is not completely obvious either.  People can
customize the modeline any way they want, or even elect to have no
modeline.  So even if the _default_ modeline would mention the working
buffer, this would not necessarily make ielm-print-working-buffer
irrelevant for everybody.

Sincerely,

Luc.

Re: IELM prompt

[Richard Stallman]

The changes look good to me.

Re: IELM prompt

[Juanma Barranquero]

On Fri, 23 Apr 2004 17:59:11 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> The ":run" may not provide that
> much information, but, on the other hand, it is not completely
> redundant.

[snip]

> People can
> customize the modeline any way they want, or even elect to have no
> modeline.

You're right on both accounts.

What about this much less intrusive patch, then?

                                                           /L/e/k/t/u


Index: ielm.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ielm.el,v
retrieving revision 1.37
diff -u -2 -r1.37 ielm.el
--- ielm.el	23 Apr 2004 21:33:38 -0000	1.37
+++ ielm.el	24 Apr 2004 23:26:15 -0000
@@ -415,6 +415,6 @@
 is preserved between successive evaluations.  In this way, expressions
 may be evaluated in a different buffer than the *ielm* buffer.
-Display the name of the working buffer with \\[ielm-print-working-buffer],
-or the buffer itself with \\[ielm-display-working-buffer].
+By default, its name is shown on the mode line; you can always display
+it with \\[ielm-print-working-buffer], or the buffer itself with \\[ielm-display-working-buffer].
 
 During evaluations, the values of the variables `*', `**', and `***'
@@ -453,4 +453,5 @@
   (setq major-mode 'inferior-emacs-lisp-mode)
   (setq mode-name "IELM")
+  (setq mode-line-process '(":%s on " (:eval (buffer-name ielm-working-buffer))))
   (use-local-map ielm-map)
   (set-syntax-table emacs-lisp-mode-syntax-table)

Re: IELM prompt

[Luc Teirlinck]

Juanma Barranquero wrote:

   What about this much less intrusive patch, then?

That might be good.

Sincerely,

Luc.

Re: IELM prompt

[Juanma Barranquero]

Related to the read-onliness of the IELM prompt:

M-x ielm =>
  * Welcome to IELM ***  Type (describe-mode) for help.
  ELISP> 

C-c C-c  =>
  Process ielm interrupt

M-x ielm =>
  *** Welcome to IELM ***  Type (describe-mode) for help.

with no prompt, and a message: "Text is read-only".

A way to fix it is with the attached patch, which:

  - wraps the insertion of the header on a
    (let ((inhibit-read-only t))
       ...)

  - adds a call to (goto-char (point-max)) at the end of `ielm',
    because, as it stands, `inferior-emacs-lisp-mode' can not change the
    point when invoked from inside the *ielm* buffer (as happens while
    restarting the ielm process).

Personally, I think it'd be better to just do

  (when (= (point-min) (point-max))
    ;; Add a silly header
    (insert ielm-header)
     ...)

and *not* insert the header when restarting the process, just when the
*ielm* buffer is created the first time around.

Opinions?

                                                           /L/e/k/t/u



Index: ielm.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ielm.el,v
retrieving revision 1.38
diff -u -2 -r1.38 ielm.el
--- ielm.el	24 Apr 2004 22:56:34 -0000	1.38
+++ ielm.el	25 Apr 2004 00:32:15 -0000
@@ -519,7 +519,9 @@
     (ielm-set-pm (point-max))
     (unless comint-use-prompt-regexp-instead-of-fields
-      (add-text-properties
-       (point-min) (point-max)
-       '(rear-nonsticky t field output inhibit-line-move-field-capture t)))
+      (let ((inhibit-read-only t))
+        (add-text-properties
+         (point-min) (point-max)
+         '(rear-nonsticky t field output inhibit-line-move-field-capture t))))
+
     (comint-output-filter (ielm-process) ielm-prompt)
     (set-marker comint-last-input-start (ielm-pm))
@@ -551,5 +553,6 @@
       (set-buffer (get-buffer-create "*ielm*"))
       (inferior-emacs-lisp-mode)))
-  (pop-to-buffer "*ielm*"))
+  (pop-to-buffer "*ielm*")
+  (goto-char (point-max)))
 
 (provide 'ielm)

Re: IELM prompt

[Luc Teirlinck]

Juanma Barranquero wrote:

   Personally, I think it'd be better to just do

     (when (= (point-min) (point-max))
       ;; Add a silly header
       (insert ielm-header)
	...)

   and *not* insert the header when restarting the process, just when the
   *ielm* buffer is created the first time around.

   Opinions?

The header in:

ELISP>   C-c C-c
Process ielm interrupt
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP>

gives an indication that the process was restarted.  (Maybe it can be
argued that the new prompt already does that.)  _Maybe_:

ELISP>   C-c C-c
Process ielm interrupt
Process ielm restarted
ELISP>
 
might be better, but probably the repeated header is good enough.

Sincerely,

Luc.

Re: IELM prompt

[Juanma Barranquero]

On Sat, 24 Apr 2004 20:27:31 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> but probably the repeated header is good enough.

Well, in that case the problem detailed in my message still has to be
resolved.

I'll update my patch (there's a slight problem on it) and install it.

                                                           /L/e/k/t/u

Re: IELM prompt

[Luc Teirlinck]

I now believe there is a problem with your latest patch to ielm.el.
If one is working in an *ielm* buffer, then switch to other buffers,
then do M-x ielm to return to the *ielm* buffer, one does usually
_not_ want point to move to the end, without even having a marker set
to go back.  You can do RET on any prompt.  In the case of reenabling
ielm after it was interrupted, the probability of the user wanting to
go to the end is bigger, but not equal to 1.

The behavior _before_ your patch did not make sense either.  If one
did M-x ielm on an interrupted process, one went to the end if and
only if the ielm buffer is not current at the time one does M-x ielm.
But it is exactly when the ielm buffer is _not_ current that one
might want to see where point used to be after switching to the *ielm*
buffer.  No mark is set, so that information is irretrievable lost.

I believe that if one switches back to an active ielm process, point
should stay where it is.  For an interrupted process, two possible
solutions are to always stay, or to always move to the end, but
setting the mark, so the user can easily go back.  The patch below
implements the latter.  I could commit if there are no objections.

===File ~/ielm.el-diff======================================
*** ielm.el	25 Apr 2004 12:14:17 -0500	1.39
--- ielm.el	25 Apr 2004 14:02:34 -0500	
***************
*** 547,559 ****
    "Interactively evaluate Emacs Lisp expressions.
  Switches to the buffer `*ielm*', or creates it if it does not exist."
    (interactive)
!   (if (comint-check-proc "*ielm*")
!       nil
!     (save-excursion
!       (set-buffer (get-buffer-create "*ielm*"))
!       (inferior-emacs-lisp-mode)))
!   (pop-to-buffer "*ielm*")
!   (goto-char (point-max)))
  
  (provide 'ielm)
  
--- 547,559 ----
    "Interactively evaluate Emacs Lisp expressions.
  Switches to the buffer `*ielm*', or creates it if it does not exist."
    (interactive)
!   (let (old-point)
!     (unless (comint-check-proc "*ielm*")
!       (with-current-buffer (get-buffer-create "*ielm*")
! 	(unless (eq (buffer-size) 0) (setq old-point (point)))
! 	(inferior-emacs-lisp-mode)))
!     (pop-to-buffer "*ielm*")
!     (when old-point (push-mark old-point))))
  
  (provide 'ielm)
  
============================================================

Re: IELM prompt

[Juanma Barranquero]

On Sun, 25 Apr 2004 14:35:45 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> The behavior _before_ your patch did not make sense either.

Sure. In fact, for an interrupted process the point ended at the start
of the header :)

> I believe that if one switches back to an active ielm process, point
> should stay where it is.

Yes, it sound logical. I didn't think of it because my pattern of usage
of ielm is very different. In fact, I have a wrapper function for ielm
which shows the ielm buffer in a small window at the bottom of the frame,
and takes it out of view when not using it (that's how I found the
problem with `where-is-internal': I bind a global key to "enter" into
the ielm buffer/window, and the same key in the local ielm map to hide
the window and go back to where I was).

> I could commit if there are no objections.

Not mine.

Thanks,


                                                           /L/e/k/t/u