From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: emacs-devel@gnu.org
Subject: Re: Minor gdb-ui patches to make it a bit more robust
Date: Wed, 20 Feb 2008 17:00:01 -0500 [thread overview]
Message-ID: <jwvd4qrwb6l.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <18363.27328.477290.549149@kahikatea.snap.net.nz> (Nick Roberts's message of "Wed, 20 Feb 2008 12:48:16 +1300")
>> > 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
prev parent reply other threads:[~2008-02-20 22:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-18 21:08 Minor gdb-ui patches to make it a bit more robust Stefan Monnier
2008-02-18 22:12 ` Nick Roberts
2008-02-19 2:42 ` Stefan Monnier
2008-02-19 9:42 ` Andreas Schwab
2008-02-19 10:11 ` Nick Roberts
2008-02-19 15:57 ` Stefan Monnier
2008-02-19 23:48 ` Nick Roberts
2008-02-20 22:00 ` Stefan Monnier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvd4qrwb6l.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=nickrob@snap.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.