Re: Minor gdb-ui patches to make it a bit more robust

[Stefan Monnier]

>> > The flexibility of the command line means that there are always ways round
>> > these types of checks.  For example, the prompt can be changed, e.g when
>> 
>> Of course, I'm not deluding myself: these are nothing more than sanity
>> checks, but they can come *real* handy to the user.  I wasted a good 10
>> minutes trying to understand why my GDB was not responsive.

> It's a reliability issue in't it?  Even if your patch works for 99% of
> users, it still means the other 1% will be exasperated and go round
> saying that gdb-ui is buggy.

No, it's not a reliability issue.  It's a convenience issue.  Similar to
the check we add to detect "you've loaded an old version of CUA-mode":
it won't catch all cases, but will help most victims of the change
figure out quickly what's going on.  So it's perfectly OK to only catch
99% of the cases.  As I said, we may prefer to signal an error (or even
just a (loud) message) rather than fallback automatically to the old
gud-gdb code.

> OK, I'm still not sure how it would all work.  Perhaps, if, on the trunk,
> you initialise one or two variables this way I can do the rest by following
> the idiom.

I'll see if I find time to do it.  Basically, you want to replace

     (setq gdb-foo bar)
with
     (process-put <proc> 'foo bar)

and

     gdb-foo
with
     (process-get <proc> 'foo)

Of course, at first this will be very awkward because <proc> is not
immediately available, so you'll need (get-buffer-process
(current-buffer)) or somesuch.  And worse yet, some of the code is not
always run in the *gud* buffer, so we'll need (with-current-buffer
<gudbuf> (get-buffer-process (current-buffer))).

We may also prefer to move some of the global vars to buffer-local
rather than process-local.  In that case some of the code will stay as
is, and other will need some (with-current-buffer <gudbuf> ...) wrappers.

>> I don't see in what way that would make any difference: global variables
>> will still be a source of bugs (and will still prevent the co-existence
>> of multiple gdb-ui processes in the same Emacs instance).

> I just mean that there will be a lot of churn, at some stage, so I didn't
> want to anyone to waste energy on the annotation side of things.

That makes sense, indeed.

>> >> PS: Is there any hope for GDB to accept a command that puts it in
>> >> annotate=3 mode, rather than having to tweak the command line for it?
>> >> That would solve a lot of those problems.
>> 
>> > Yes, if you mean "set annotate 3".
>> 
>> So is there any hope to make gdb-ui rely on that rather than
>> on --annotate=3?

> Yes.  I guess that is another possible way to solve the initialisation
> problems (and keep text command mode available to M-x gdb).

Then, I strongly encourage you to make such a change to gdb-ui.
If you could make a similar change to gud-gdb (so it sends
"set annotate 2" I guess), that would be great.


        Stefan