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

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

[Miles Bader]

Customize the comint prompts to be read-only (in customize group
"comint"), then try starting a gdb session and typing some commands.

You get various "text is read-only" errors, and things generally don't
work right.

Thanks,

-Miles


In GNU Emacs 22.0.50.67 (i686-pc-linux-gnu, GTK+ Version 2.8.3)
 of 2005-10-17 on dhapc248.dev.necel.com
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-x-toolkit=gtk' '--without-xim''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ja_JP.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  display-time-mode: t
  file-name-shadow-mode: t
  minibuffer-electric-default-mode: t
  recentf-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
. h <return> C-s r e g _ u n u s e d C-a C-q C-q C-q 
C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q 
C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q C-q 
C-q C-q C-q C-q <switch-frame> <help-echo> <switch-frame> 
C-x d C-x d C-x b * g u SPC <return> <switch-frame> 
<escape> x s 9 <return> <switch-frame> <escape> x s 
9 <return> m s <return> C-x b <return> <down-mouse-1> 
<mouse-movement> <mouse-1> <switch-frame> <switch-frame> 
<escape> x r e p o r t - e m a c s <return>

Recent messages:
Scanning ` *Gnus Backlog*'
Scanning `diagnostic.c'
Scanning `*Customize Group: Comint*'
Scanning `*partial-output-cc1*'
Scanning `*breakpoints of cc1*'
Scanning `.newsrc-dribble'
Scanning `*Quail Completions*'
dabbrev-expand: No dynamic expansion for `*chain->dead' found
Mark saved where search started
Loading emacsbug...done

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

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

[Nick Roberts]

 > Customize the comint prompts to be read-only (in customize group
 > "comint"), then try starting a gdb session and typing some commands.
 > 
 > You get various "text is read-only" errors, and things generally don't
 > work right.

You get the same errors with "gdb -fullname" if you execute commands using the
toolbar or keybindings e.g C-x C-a C-n.  That's because GUD deletes the
existing prompt in this and replaces it with the new one.  The variable
comint-prompt-read-only is quite new.  Why would someone set it to t?

Nick

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

[Nick Roberts]

 > > You get the same errors with "gdb -fullname" if you execute commands using
 > > the toolbar or keybindings e.g C-x C-a C-n.  That's because GUD deletes
 > > the existing prompt in this and replaces it with the new one.  The
 > > variable comint-prompt-read-only is quite new.  Why would someone set it
 > > to t?

 > Because it helps the user avoid mucking up his prompt.  If gud can't
 > avoid mucking with it, it should be binding `inhibit-read-only' around
 > the place where it mucks.

I've tried to do that.  Does it work now?

Nick

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

[Richard M. Stallman]

    You get the same errors with "gdb -fullname" if you execute commands using the
    toolbar or keybindings e.g C-x C-a C-n.  That's because GUD deletes the
    existing prompt in this and replaces it with the new one.  The variable
    comint-prompt-read-only is quite new.  Why would someone set it to t?

We're not going to remove the feature, so let's not go off on a
tangent about that.  GUD ought to work when that variable is set.

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

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

[Nick Roberts]

 >     You get the same errors with "gdb -fullname" if you execute commands
 >     using the toolbar or keybindings e.g C-x C-a C-n.  That's because GUD
 >     deletes the existing prompt in this and replaces it with the new one.
 >     The variable comint-prompt-read-only is quite new.  Why would someone
 >     set it to t?
 > 
 > We're not going to remove the feature, so let's not go off on a
 > tangent about that.  GUD ought to work when that variable is set.

I don't think it was a tangent.  I hadn't heard of this variable before Miles
drew my attention to it and the Lisp manual doesn't describe it.

 > 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.

Nick

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.

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

[Nick Roberts]

 > 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))

I looked more carefully and although using inhibit-read-only stopped the
error, I noticed that the old prompt wasn't being deleted and prompts were
accumulating.  This only happened if you issued a GDB command from outside the
GUD buffer e.g gud-next from the tool bar (if the command is typed in the GUD
buffer, you want to keep the old prompt).  I'm not sure exactly why using
comint-update-fence solves the problem, but I've installed your change anyway.

Thanks,

Nick