In my opinion we should very much make the gdb-ui code the default.
As for keeping support for --fullname, I believe it's needed as long as the
gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the
current state of affairs, but I've had to switch to --fullname
Stefan Monnier [EMAIL PROTECTED] writes:
In my opinion we should very much make the gdb-ui code the default.
As for keeping support for --fullname, I believe it's needed as long as the
gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the
current state of affairs, but
From: Nick Roberts [EMAIL PROTECTED]
Date: Sat, 14 Jul 2007 12:21:55 +1200
Cc: emacs-pretest-bug@gnu.org
IMO, it's not nice to change the package semantic in such radical ways
behind users' backs. I know a few people who like the current M-x gdb
and will not be pleased to see the
Stefan Monnier [EMAIL PROTECTED] writes:
+ (if (case gud-gdb-annotations
+(2 nil)
+(nil (string-match --annotate=3 command-line))
FWIW, this should be `((nil) ...)'. `nil' means an empty KEYLIST
(which always fails).
The manual says
To make a clause that matches the
On 7/14/07, Eli Zaretskii [EMAIL PROTECTED] wrote:
??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a
program? Are you saying it is hard to check the value of a single
variable and invoke one of two functions depending on that? What am I
missing here?
Animism?
IMO, it's not nice to change the package semantic in such radical ways
behind users' backs. I know a few people who like the current M-x
gdb and will not be pleased to see the GUI version instead.
It's not nice trying to get Emacs to work out which option has been
How about if we modify M-x gdb to invoke gdb-ui if a certain option is
set? Whether this option should be on or off by default, is another
matter, but at least users will be able to control what UI they get by
flipping a single option.
Most users will just use the default until it causes
To make a clause that matches the actual symbol `t', `nil', or
`otherwise', enclose the symbol in a list.
Thanks for catching it. Not that it mattered since this was intended for
human consumption exclusively: don't ever pass it to `patch' or try to
splice the code in by hand either.
2007/7/13, Nick Roberts [EMAIL PROTECTED]:
I think that M-x gdb doesn't work in you start execution from within a
script. In this case you must use M-x gdba. Does this work?
Yes! What's the difference betweeen gdb and gdba? I wasn't able to
find anything documenting the difference,
...What's the difference betweeen gdb and gdba? I wasn't able to
find anything documenting the difference, according to the docs they
seem to do roughly the same thing.
M-x gdba assumes that GDB is being run with the --annotate=3 option. M-x
gdb filters the output to determine
From: Nick Roberts [EMAIL PROTECTED]
Date: Fri, 13 Jul 2007 23:26:20 +1200
Cc: emacs-pretest-bug@gnu.org
This is a suggestion to the mailing list, but also a RFA to RMS. Now that
gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to gdb
on the trunk so that the new
How about if we modify M-x gdb to invoke gdb-ui if a certain option
is set? Whether this option should be on or off by default, is
another matter, but at least users will be able to control what UI
they get by flipping a single option.
Yes, I suggest the following:
- introduce a new custom
IMO, it's not nice to change the package semantic in such radical ways
behind users' backs. I know a few people who like the current M-x gdb
and will not be pleased to see the GUI version instead.
I agree.
How about if we modify M-x gdb to invoke gdb-ui if a certain option
This is a suggestion to the mailing list, but also a RFA to RMS. Now that
gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to
gdb on the trunk so that the new mode takes the focus?
IMO, it's not nice to change the package semantic in such radical ways
behind
Stefan Monnier writes:
How about if we modify M-x gdb to invoke gdb-ui if a certain option
is set? Whether this option should be on or off by default, is
another matter, but at least users will be able to control what UI
they get by flipping a single option.
Yes, I suggest the
IMO, it's not nice to change the package semantic in such radical ways
behind users' backs. I know a few people who like the current M-x gdb
and will not be pleased to see the GUI version instead.
I agree.
Perhaps being disruptive sometimes is a good thing.
How
In GNU Emacs 23.0.0.1 (i486-pc-linux-gnu, GTK+ Version 2.10.11)
of 2007-07-06 on helios
I have GNU gdb 6.6-debian and it works fine with GNU Emacs 23.0.0.3
(i686-pc-linux-gnu, GTK+ Version 2.10.11).
Does it fail with Emacs 22.1?
I'm having the same or very similar problems on Solaris /
I'm attaching a new debug log where I've gone one step further and
done f in the GDB pane to get the source window to refresh. That
did get me a bunch of error messages which might make this log a bit
more interesting to you.
It still doesn't seem to contain the errors but I don't think
18 matches
Mail list logo
