[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Minor gdb-ui patches to make it a bit more robust
From: |
Stefan Monnier |
Subject: |
Re: Minor gdb-ui patches to make it a bit more robust |
Date: |
Wed, 20 Feb 2008 17:00:01 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>> > 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