From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27907 invoked by alias); 20 Sep 2005 19:39:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27829 invoked by uid 22791); 20 Sep 2005 19:39:20 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 20 Sep 2005 19:39:20 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2BDC947E75; Tue, 20 Sep 2005 12:39:18 -0700 (PDT) Date: Tue, 20 Sep 2005 19:39:00 -0000 From: Joel Brobecker To: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] print arrays with indexes Message-ID: <20050920193918.GB10186@adacore.com> References: <20050918034639.GB6990@nevyn.them.org> <20050918054109.GD2496@adacore.com> <20050918191943.GA27191@nevyn.them.org> <20050920073058.GR2496@adacore.com> <20050920193132.GY2496@adacore.com> <20050920193339.GA28294@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920193339.GA28294@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-09/txt/msg00180.txt.bz2 > I'm confused. Wasn't Jim's point that he wanted "on for large arrays > only, too ugly for small arrays"? Which is the first. That was the reason why I asked, because I sensed some disparity between what people wanted. In my particular case, it doesn't matter, because I will turn the feature on on a as-needed basis, so won't use the threshold. However, the cases where I have needed it are when the array was too big for me to do the counting... So Jim's point makes more sense to me too. > It sounds like we have legitimate reasons for both thresholds. I'm > getting more inclined to implement neither for now, to prevent confusion. This sounds good to me too. Perhaps a compromise between what Eli suggested and what you have been suggesting would work. How about we implement a on/off knob for now. Later on, if we understand better in which direction to use the threshold, then we can enhance the knob to include "auto", and then have a second knob. As long as we cross-reference each setting in the help text, I think users won't be confused. -- Joel