Re: Comint read-only-prompt

[JD Smith]

On Tue, 2005-06-07 at 12:38 -0500, Luc Teirlinck wrote:
> JD Smith wrote:
> 
>    I just compiled a CVS Emacs v22, and was pleased to find that there is
>    a new comint- prompt-read-only variable.  However, when I enable that
>    variable, I get the following non-desired behavior:
> 
>       1. At each prompt, I am warned "Text is read-only".
>       2. All my input is echoed back to me (I use process-echoes).  
> 
>    I thought my prompt pattern could be at fault; it contains a \r
>    character (which IDL throws in at odd intervals).  I changed it to
>    something simple, and get the same behavior.
> 
> Unless you set comint-use-prompt-regexp (formerly
> comint-use-prompt-regexp-instead-of-fields) to t, the value of
> shell-prompt-pattern will not matter very much.  It looks like part of
> the echoed input is considered part of the prompt.  The prompt
> read-only region includes the prompt and the newline before it.
> 
> It is really difficult for me to look into this, because I can not
> duplicate the problem.  Trying to use idlwave-shell-mode (assuming
> that is what we are talking about) I got:
> 
> apply: Searching for program: no such file or directory, idl

I turned on comint-use-prompt-regexp, with the same results.  I have
comint-process-echoes set, since IDL echoes input.  If I turn it off, I
don't get the "Text is read-only" warning, but of course get the echoed
input.  It appears that comint is attempting to delete some of the input
which has already been marked read-only as a result of prompt-read-only.
I've isolated the "Text is read-only" warning to line 1550 of comint.el:

                  (delete-region comint-last-input-end
                                 (+ comint-last-input-end echo-len)))))

This is in the segment of code which removes the duplicate input echoed.
When process-echoes is set, this gets called, and results in the warning
above.  This results because the echoed input has apparently already
been marked read-only, perhaps by having inherited that status from the
prior prompt somehow.  Here is an example input which delete-region
failed to delete after having matched it:

#("print,'foo'\n" 0 9 (front-sticky (read-only) read-only t inhibit-
line-move-field-capture t field output rear-nonsticky t) 9 12 (inhibit-
line-move-field-capture t field output rear-nonsticky t))

Thanks,

JD