From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1578 invoked by alias); 23 Dec 2013 17:40:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1567 invoked by uid 89); 23 Dec 2013 17:40:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f49.google.com Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 23 Dec 2013 17:40:23 +0000 Received: by mail-wg0-f49.google.com with SMTP id x12so5248000wgg.16 for ; Mon, 23 Dec 2013 09:40:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr12390395wjn.41.1387820419736; Mon, 23 Dec 2013 09:40:19 -0800 (PST) Received: by 10.194.123.4 with HTTP; Mon, 23 Dec 2013 09:40:19 -0800 (PST) In-Reply-To: <87sitnij45.fsf@fleche.redhat.com> References: <52A1C990.1010703@redhat.com> <87sitnij45.fsf@fleche.redhat.com> Date: Mon, 23 Dec 2013 17:40:00 -0000 Message-ID: Subject: Re: [PATCH 00/13] script language API for GDB From: Doug Evans To: Tom Tromey Cc: Phil Muldoon , "gdb-patches@sourceware.org" , guile-user@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00890.txt.bz2 [+ guile-user For background: https://sourceware.org/ml/gdb-patches/2013-12/msg00243.html ] On Fri, Dec 20, 2013 at 8:26 AM, Tom Tromey wrote: >>>>>> "Doug" == Doug Evans writes: > > Doug> One thought I have for this is "info guile pretty-printer", etc. > Doug> That simplifies a lot of things. From a u/i perspective it has > Doug> both plusses and minuses, but I like it overall. > > The problem with this approach is that it assumes that the user both > knows and cares in which extension language a given feature is > implemented. However, I don't believe either of those is true in the > most common situations. My experience with the libstdc++ printers is > that most people want them to "just work" and that any amount of > required under-the-hood knowledge is too much of a burden. OTOH, there are situations where a user can care. For those that don't care, "info pretty-printer" can still print all of them. "info pretty-printer" et.al. would need some work, sure, and one way to go would be to use "info pretty-printer".