This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 1/3] Use function_name_style to print Ada and C function names


> >>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
> 
> Philippe> ada-typeprint.c:print_func_type is only called to print types that are
> Philippe> functions.  So, that effectively prints a function name.
> 
> No opinion on that one, maybe Joel could say.

I tried to think about the general context, and the guideline in
my mind is that there is a fine line where coloring is helpful and
when it becomes too much, reducing the effectiveness of colorization.
In this case, this patch seems to advocate in favor of colorization?

Perhaps we might indeed find it useful to colorize type names.
But, for the sake of consistency, let's color all type names,
rather than just function ones. And perhaps one thing we could do
to avoid an explosion of colorization options, which themselves
can lead to visual-confusion-by-color-mosaic effect, is to compromise
a bit by saying type names should be styled similarly to their object
counterparts.  Eg: same colour, but with a "dim" filter? For instance,
if addresses are in blue, then types which are pointers/refs, etc,
could be printed in dim blue?

One thing I might do, regardless of the decision, is define in the code
a different style for this kind of entity, even if, internally, the style
itself is just a reference (an "alias", if you will), of an existing
style. That way, it is easier to keep track of the various kinds of
entities and their style, thus allowing us the option of upgrading
this kind of entities to their own style if we wanted to.  Otherwise,
we'd have to audit all the existing calls to styling to see which
ones we want to style separately.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]