From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=YAPR=AS=gnu.org=eliz@sourceware.org>
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10])
	by sourceware.org (Postfix) with ESMTPS id B490F3858C31
	for <gdb-patches@sourceware.org>; Thu, 27 Apr 2023 09:10:13 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B490F3858C31
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org
Received: from fencepost.gnu.org ([2001:470:142:3::e])
	by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	(envelope-from <eliz@gnu.org>)
	id 1prxdk-0000we-Tm; Thu, 27 Apr 2023 05:10:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
	s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
	mime-version; bh=xRJM1qQYjL8KXVRJtBSzr0WJpFRK+ERADVsDkkdzhNQ=; b=clvyzKGnvb0F
	38ZfwdI5IzTpJsgqlk48lXRwRhDDLyrjmtBUbMkDuJWo+LQTBbmaUs+DPRbizjrFrUomAjiAPMI+s
	0balVuqqCFJU4GQiER6SwMMnCJekD1ibLh8+eJqB7LIGg0blE79lI2ZjmoIiS4HXH/OW4E941vGZB
	cqZWNX0/lVj4hvfbDdKj9Y/NoeY5pqWST0O5JdN90U/pDfBHX0c+6p5kAZW49cXZjrwInu7RV0FpA
	+WTnHte+3F85q1yp2t8zEjIE/qlHSOVjWMKaTvC8mVlzB7YWk23tfP+JEZgb7VuWIG0kXXcVoldUp
	+dE5IGmvO+//vPevcAMvcQ==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
	by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	(envelope-from <eliz@gnu.org>)
	id 1prxdk-00027d-4J; Thu, 27 Apr 2023 05:10:12 -0400
Date: Thu, 27 Apr 2023 12:10:43 +0300
Message-Id: <83y1mdsnak.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Luis Machado <luis.machado@arm.com>
Cc: gdb-patches@sourceware.org
In-Reply-To: <11f9bfb1-78cb-80db-fbc6-3262f0f9fdae@arm.com> (message from Luis
	Machado on Thu, 27 Apr 2023 09:35:15 +0100)
Subject: Re: [PATCH,v3 17/17] [gdb/docs] sme: Document SME registers and
 features
References: <20230411042658.1852730-18-luis.machado@arm.com>
 <20230417171945.328823-1-luis.machado@arm.com> <83ttx81dcc.fsf@gnu.org>
 <d1dc7f33-85df-fbe7-46a4-da86789a70c2@arm.com> <83bkjatyi2.fsf@gnu.org> <11f9bfb1-78cb-80db-fbc6-3262f0f9fdae@arm.com>
X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gdb-patches.sourceware.org>

> Date: Thu, 27 Apr 2023 09:35:15 +0100
> Cc: gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> >>> This should use @var, not @code.  Also, I'd remove the whitespace
> >>> around "x".
> >>
> >> Fixed. But I used spaces between "x" and the two @var entries because it gets rendered as a single
> >> block of characters like svlxsvl.
> > 
> > That doesn't seem possible, since @var produces a different typeface:
> > slanted in the printed version and CAPS in the Info versions.  Where
> > did you see svlxsvl?
> 
> In the PDF. I mean, it is slanted with the use of @var{}, but not that noticeable.
> 
> See the attached pdf. I also attached the info file.

Then maybe use "@var{svl} by @var{svl}"?

> I noticed the info file capitalizes @var{}, which might not be ideal?

That cannot be helped.  It isn't ideal, indeed, but given that Info
manuals must be displayed on plain-text terminals, there's not a lot
Texinfo can play with.