From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-156649-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 95442 invoked by alias); 5 Jun 2019 13:42:39 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 95434 invoked by uid 89); 5 Jun 2019 13:42:39 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: gateway34.websitewelcome.com
Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.149.62) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Jun 2019 13:42:37 +0000
Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8])	by gateway34.websitewelcome.com (Postfix) with ESMTP id 529109B9AE	for <gdb-patches@sourceware.org>; Wed,  5 Jun 2019 08:42:36 -0500 (CDT)
Received: from box5379.bluehost.com ([162.241.216.53])	by cmsmtp with SMTP	id YWBYhRsDGiQerYWBYh13V9; Wed, 05 Jun 2019 08:42:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com;	 s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:	References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:	List-Subscribe:List-Post:List-Owner:List-Archive;	bh=Dl/NZZ8G40nhHapUdjA3ZcZQZU7CcxKjhun2j1By7EQ=; b=q34W0Inr49HWRlD7HV0YCo43Jn	Y6oascss57BuQ6RpQ2/7KWP3edvXrtnlmWowJpsDFBabdqTWTSWmqX3fP2avdMMofcKw9vP46CXtQ	vsdSVgbF/DzAFEDkSGznkbVMo;
Received: from 174-29-48-168.hlrn.qwest.net ([174.29.48.168]:37418 helo=murgatroyd)	by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)	(Exim 4.91)	(envelope-from <tom@tromey.com>)	id 1hYWBY-00014P-1C; Wed, 05 Jun 2019 08:42:36 -0500
From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
Subject: Re: [PATCH] Style "pwd" output
References: <20190605020116.1550-1-tom@tromey.com>	<1ee4bd6b-4cdf-f3a9-74af-0843bf123a8b@redhat.com>
Date: Wed, 05 Jun 2019 13:42:00 -0000
In-Reply-To: <1ee4bd6b-4cdf-f3a9-74af-0843bf123a8b@redhat.com> (Pedro Alves's	message of "Wed, 5 Jun 2019 09:36:23 +0100")
Message-ID: <87lfygi1x0.fsf@tromey.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2019-06/txt/msg00123.txt.bz2

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I wish we didn't have to split the lines across different calls though.
Pedro> I know we don't officially do i18n yet (*), but these kinds of changes will
Pedro> only make it more difficult to get there.

Pedro> Maybe with something like:

Pedro>   if (strcmp (cwd.get (), current_directory) != 0)
Pedro>     printf_unfiltered (_("Working directory <style=filename>%s<style/>\n (canonically <style=filename>%s<style/>).\n"),
Pedro> 		       current_directory, cwd.get ());
Pedro>   else
Pedro>     printf_unfiltered (_("Working directory <style=filename>%s<style/>.\n"), current_directory);

Pedro> I'm sure you've considered something like that; I think we've discussed it
Pedro> before.  What are your current thoughts?

I think what would be nice is a gdb-specific printf extension for this,
e.g.:

    printf_unfiltered ("Working directory %<%s%>\n",
                       ui_out_style_kind::FILE, 
                       current_directory);

%< takes a style argument and %> does not.

However, for that to work, we'd need a GCC enhancement to let gdb modify
the printf format checking.


Note that if we want to be serious about i18n then there is also the
problem that the whole MI approach is not very i18n-friendly.  There are
spots that split calls like this, but which can't easily be unsplit
(even with a printf extension) due to MI.  So maybe something bigger is
needed.

Tom