Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: add macro commands
Date: Fri, 10 May 2002 08:55:00 -0000	[thread overview]
Message-ID: <npznz86lq6.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <8011-Fri10May2002101418+0300-eliz@is.elta.co.il>


"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > From: Jim Blandy <jimb@redhat.com>
> > Date: Thu,  9 May 2002 18:58:22 -0500 (EST)
> > 
> > +   add_cmd
> > +     ("expand", no_class, macro_expand_command,
> > +      "Fully expand any C/C++ preprocessor macro invocations in EXPRESSION.\n"
> > +      "Show the expanded expression.",
> > +      &macrolist);
> 
> Do I understand correctly that this command definition, as well as
> others you added in this patch, makes the command use the default
> completion function?  If so, I'm not sure that's a good idea, unless
> the tables scanned by make_symbol_completion_list store macro names.
> 
> It would be nice to have completion only on macro names in these
> commands.  But if that cannot be done easily, at least let's disable
> completion entirely until something appropriate is coded.

I hadn't thought about completion at all.

Given that the macros are stored in a splay tree, they're all sorted
in a way that would make efficient completion straightforward.  So it
wouldn't be too hard to write a macro-only completion function.

But the argument is an expression.  People may want to use real
variable names in the expressions they expand: they may not want to
substitute short dummy names for the long variable names in the
expression they have inmind.  So why should it complete differently
from other expressions?  Why shouldn't GDB help people use long
variable names in their expressions to expand?

I think a better change would be to simply include macro names in the
completion process.


  reply	other threads:[~2002-05-10 15:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-09 16:58 Jim Blandy
2002-05-09 17:13 ` Daniel Jacobowitz
2002-05-09 20:43   ` Jim Blandy
2002-05-09 17:54 ` Andrew Cagney
2002-05-09 20:43   ` Jim Blandy
2002-05-10  0:16 ` Eli Zaretskii
2002-05-10  8:55   ` Jim Blandy [this message]
2002-05-10  9:33     ` Eli Zaretskii
2002-05-10 16:07     ` Neil Booth
2002-05-11  0:16       ` Eli Zaretskii
2002-05-11  3:45         ` Neil Booth
2002-05-11 13:06       ` Jim Blandy
2002-05-16 14:17 ` Jim Blandy

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=npznz86lq6.fsf@zwingli.cygnus.com \
    --to=jimb@redhat.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    /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