Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob@brasko.net>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Removal of markup annotations
Date: Tue, 21 Jun 2005 10:22:00 -0000	[thread overview]
Message-ID: <20050621102240.GA3111@white> (raw)
In-Reply-To: <17079.42964.633253.582441@farnswood.snap.net.nz>

On Tue, Jun 21, 2005 at 05:38:28PM +1200, Nick Roberts wrote:
>  > Well, it is not as easy for me to just parse the output without the
>  > annotations. Since I am still going to use annotate=2 (we are not
>  > depricating the whole thing, right?), then if you remove the breakpoints
>  > markup I'll have to handle old GDB's that have the markup, and new GDB's
>  > that don't.
>  > 
>  > This would be a serious pain.
> 
> Its not that hard to do.  You have to filter the annotations in any case.
> Emacs in CVS works with --annotate=2 or --annotate=3.  Lisp is ideally suited
> to this kind of thing, but I think it should be quite straightforward in C
> too.  An association list stores a list of keys (the annotations) with an
> associated value (a function to call).  There are no keys for the markup
> annotations so it just ignores them.

OK, I'm extremly busy, but I'll look at this some more. Please give me a
little time before the breakpoint annotations go, if they go at all.

>  > I really only need 3 annotations out of the ones you are removing.
>  > breakpoint-table (to set a state that breakpoints are coming), field 5
>  > (which we could rename to breakpoint-at), and breakpoint-table-end (to
>  > set a state that the breakpoints are over.
>  > 
>  > To make things even easier, there could simply be a -breakpoint-begin,
>  > and a -breakpoint-end annotation, and those two annotations could mark
>  > up around the breakpoint. Would this clean up the code in breakpoint.c at
>  > all?
> 
> I don't think we should introduce new annotations.  Until now I've never
> really looked at breakpoint.c.  I've just submitted this patch to make it less
> likely that they all get removed when I'm not following the mailing list.
> 
> If no-one else is interested in their removal, I will just submit another
> much smaller patch that removes the breakpoints-invalid and frames-invalid
> from level 3, which AFAIK only Emacs uses.

Wait, don't get me wrong. I support the patch, it was just those few
(breakpoint markup) annotations that will mess me up. The other 20 or so 
are good to go as far as I'm concerned. In fact, they are buggy, and are
not reliable. I submitted bug reports 2 years ago and Andrew  told me
that they would not be fixed.

Bob Rossi


  reply	other threads:[~2005-06-21 10:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-15  3:19 Nick Roberts
2005-06-15 15:41 ` Bob Rossi
2005-06-15 23:07   ` Nick Roberts
2005-06-15 23:35     ` Bob Rossi
2005-06-15 23:58       ` Nick Roberts
2005-06-21  1:41         ` Bob Rossi
2005-06-21  6:00           ` Nick Roberts
2005-06-21 10:22             ` Bob Rossi [this message]
2005-06-16  3:28       ` Eli Zaretskii
2005-06-15 17:06 ` Eli Zaretskii
2005-06-15 21:41   ` Nick Roberts
2005-06-20 11:54   ` Nick Roberts
2005-06-20 19:29     ` Eli Zaretskii
2005-06-20 21:48       ` Nick Roberts
2005-06-21  3:41         ` Eli Zaretskii
2005-06-21  7:32           ` Nick Roberts
     [not found]             ` <uacljzbgq.fsf@gnu.org>
2005-06-21 23:47               ` Nick Roberts
2005-06-22  3:25                 ` Eli Zaretskii
2005-06-22  6:22                   ` Nick Roberts
2005-07-03 19:04 ` Daniel Jacobowitz
2005-07-03 22:13   ` Nick Roberts
2005-07-03 22:45     ` Daniel Jacobowitz
2005-09-28  0:17 ` Nick Roberts
2005-09-28  2:39   ` Bob Rossi
2005-09-28  3:45   ` Daniel Jacobowitz
2005-09-28  6:40     ` Nick Roberts
2005-09-28 13:11       ` Daniel Jacobowitz
2005-09-28 22:52         ` Nick Roberts
2005-09-28 22:56           ` Daniel Jacobowitz

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=20050621102240.GA3111@white \
    --to=bob@brasko.net \
    --cc=gdb-patches@sources.redhat.com \
    --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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox