all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu>
Subject: Re: gdba probs
Date: Thu, 12 Dec 2002 08:49:54 -0500	[thread overview]
Message-ID: <200212121349.gBCDnss08775@rum.cs.yale.edu> (raw)
In-Reply-To: 15863.53945.373935.975803@nick.uklinux.net

>  > I don't see why we need to change something to the generic part of GUD.
> Currently gdb-ui.el requires gud.el. If M-x gdb can be used with "-annotate=2"
> then gud.el will require gdb-ui.el. This means they might as well be one
> (large) file doesnt it ?

Note I said "the generic part of GUD" I didn't say "gud.el".
`gud-foo' is part of the generic code, while `gud-gdb-foo' is not.

>  > > @@ -2344,6 +2347,42 @@
>  > >  
>  > >  (defun gud-filter (proc string)
>  > >    ;; Here's where the actual buffer insertion is done
>  > > +  (when (and gud-first-time (string-match
>  > > +       "\n\032\032[a-z]" string))
>  > 
>  > What if DBX outputs this same sequence?
> 
> You take the patch too literally. It should have something like:
> 
> (string-match "\n\032\032pre-prompt\|\n\032\032breakpoints-invalid" string)

And?  Same thing: some other debugger might use the exact same sequence.
Better put the test in gud-gdb-marker-filter so there's not ambiguity
and so the generic part of the code stays cleaner.

> > Clearly, we want this hack to be GDB-specific and should thus put it in
> > GDB's filter.
> 
> It could go there but you will still end up with only one file.
> So it might be better to keep M-x gdba. If, one day, it works properly,
> then M-x gdb could go.

I think those problems are mostly orthogonal.  We may want to move
all of gdb-ui.el into gud.el or instead to move all the gud-gdb-foo
stuff out of gud.el into gdb-ui.el.  But there's no hurry.
After all, a few days ago, gud-gdb-complete-filter used to call
gdba-complete-filter (or something like that) and that didn't force you to
merge things into a single file.
The ultimate goal is to merge M-x gdb and M-x gdba, but it doesn't
have to be done in a single step.  I think the first step is to make
sure that both work (maybe with quirks) regardless of whether
--annotate=2 was used or not.

Miles said:
> [Yeah I know gud.el is a big ball of hair already, but there's no sense
> in making it worse]

Which part are you thinking of ?  It's really not that bad.
It has annoying limitations due to excessive use of global state
(you can't have both a GDB and a PerlDB running at the same time),
but the code itself is pretty clean and simple if you ask me (at
least the generic part of the code is very slim AFAIK).


	Stefan

  reply	other threads:[~2002-12-12 13:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 20:40 gdba probs Nick Roberts
2002-12-05 21:49 ` Stefan Monnier
2002-12-07  2:38   ` Nick Roberts
2002-12-07  3:10     ` Miles Bader
2002-12-09 15:46     ` Stefan Monnier
2002-12-10 14:19     ` Stefan Monnier
     [not found]       ` <15862.30022.647969.267154@nick.uklinux.net>
     [not found]         ` <200212111411.gBBEBUn03805@rum.cs.yale.edu>
2002-12-11 22:27           ` Nick Roberts
2002-12-11 22:48             ` Stefan Monnier
2002-12-12  0:05               ` Nick Roberts
2002-12-12 13:49                 ` Stefan Monnier [this message]
2002-12-12 14:13                   ` Miles Bader
2002-12-13 22:21                 ` Richard Stallman
2002-12-12  1:24             ` Miles Bader
2002-12-12 10:22               ` Kim F. Storm
2002-12-15  0:36   ` Nick Roberts
2002-12-07 21:25 ` Richard Stallman
2002-12-08  1:55   ` Nick Roberts
2002-12-09 20:21     ` Richard Stallman
2002-12-10 21:39       ` Nick Roberts
2002-12-10 23:44         ` Kim F. Storm
2002-12-11 20:40         ` Richard Stallman
2002-12-08  2:27   ` Miles Bader
2002-12-10 14:14     ` Stefan Monnier
2002-12-11 17:45       ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2002-12-05  6:19 Miles Bader

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=200212121349.gBCDnss08775@rum.cs.yale.edu \
    --to=monnier+gnu/emacs@rum.cs.yale.edu \
    /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.