Re: gdb-ui doesn't work with comint read-only prompts

[Luc Teirlinck]

Nick Roberts wrote:

    > It is not hard to edit read-only text when you want to.  You just
    > bind inhibit-read-only.

   Thats what I've done although the doc string suggests there are other
   considerations that I don't understand.

Sorry for not replying earlier to this, but I needed at least some
time to check what was going on and I have been very busy with other
stuff lately.

I guess you are referring to the `comint-prompt-read-only' docstring.
That docstring explains mainly to how to safely _interactively_
override the read-only-ness of the comint prompt.

In as far as `gdb-send' is concerned, there seems to be no problem as
apparently all it does is remove face properties that have nothing to
do with read-only-ness.

`gud-filter' probably deserves a closer look.

The comint-read-only prompt is structured as follows:

prior output|
[read-only prompt] user input.

Where | denotes the newline preceding the prompt.  That newline has a
special read-only property of 'fence, indicating that the only reason
that it is read-only is to make sure that the prompt that follows stays
at the beginning of a line.

`gud-filter' apparently erases the

[read-only prompt]

leaving the read-only-ness of the previous newline intact.
If immediately afterwards a new read-only prompt is going to be
inserted by `comint-output-filter', then everything is OK.  If there
is any chance that something else than a new read-only prompt might
follow the still read-only newline, you could do
`(comint-update-fence)' with point at the beginning of the line
following the still read-only newline.  I guess that after the call to
delete-region, point is already positioned there anyway, so you could
probably do:

(let ((inhibit-read-only t))
  (delete-region (process-mark proc)
                 gud-delete-prompt-marker)
  (comint-update-fence)
  (set-marker gud-delete-prompt-marker nil))
 
_However_, as already mentioned, if a new read-only prompt is going
to be inserted at that position anyway (as I assume is the case), then
no change to the current code is necessary at all.

Sincerely,

Luc.