Re: pr 11067 patch

[Chris Moller <cmoller@redhat.com>]

On 02/19/10 13:50, Jan Kratochvil wrote:
> On Fri, 19 Feb 2010 15:53:45 +0100, Chris Moller wrote:
>    
>> The problem is that I don't know any way to change the enum
>> formatting for CLI but leave it alone for MI-.
>>      
> ...
>    
>> some way to distinguish between running under CLI vs. MI if that's the right
>> thing to do.
>>      
>
> After I wrote the patch below according to Tom Tromey the Python pretty
> printing applies even to the MI protocol values, therefore IMO it should also
> apply to this new enum printing which is also some form of pretty printing.
>
> Therefore my MI / CLI suggestion has been already rejected by the Python
> pretty printing precedence and the patch below should be dropped.
>    

How about this:  The existing patch contains a test

      if (options->summary || recurse != 0)
          fputs_filtered (TYPE_FIELD_NAME (type, i), stream);
    else {
       /* new formatting stuff */
    }

That limited the format change to unsummarised top-level "p <enum 
thingy>" circumstances.  If I make that test

      if (options->summary || recurse != 0 ||
                 ui_out_is_mi_like_p (interp_ui_out
    (top_level_interpreter ())))

i.e., checking if the print is to an MI whatever-it-is, the MI tests 
that failed under the original patch (mi-var-display and 
mi2-var-display) run okay as they originally were, which suggests to me 
that MI will go on getting enums formatted the way it expects them.  
Will that work?

Chris