[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdba probs

From: Stefan Monnier
Subject: Re: gdba probs
Date: Thu, 12 Dec 2002 08:49:54 -0500

>  > 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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]