From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mu2sM3wczmqJMAEAWB0awg (envelope-from ) for ; Tue, 13 Oct 2026 07:56:44 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=l1Xk+0YT; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B785F1E04E; Tue, 13 Oct 2026 07:56:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BCCA71E04E for ; Tue, 13 Oct 2026 07:56:43 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 05A1F4BA23DB for ; Tue, 13 Oct 2026 11:56:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05A1F4BA23DB Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=l1Xk+0YT Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 721344BA2E1F for ; Tue, 13 Oct 2026 11:56:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 721344BA2E1F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 721344BA2E1F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791892578; cv=none; b=UzjPLOc8ibr3qroTPwOZv4OYCyPxLSUcUFQTEONX8wbOOQVg5hp75Qyz7dkhEhL7CI1/QcSNHZ4gWgsWlS2rV+EpI5cBxoJB/UfsII6qoorFqjDOq+2xGHf3Tbbi3KlTz/Pb6293ltlT7OYlF3kETZ22iUJcXSQPN1X3Noajsz4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791892578; c=relaxed/simple; bh=aHh3JQsX0bmNR0Al1AxMq/uQBQJaLcUukqb/02OPtJ4=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=di4RyJDmiqYFki0o4VTkFNZbIhwkr5BCdZIW3oLXG6iwvNCrpOiOFpNmynUyd8g1p6i4Yf8IsAdg5DqdwR78Wci/wJZyttDmckKLqnB3L8KCj33IiRkI+e37luVTzqa+8wRN1oeGKmLyXwKG0iyqudFVOr6tltlwPQ4es6V9+5s= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=l1Xk+0YT DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 721344BA2E1F 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 ) id 1xGb7B-0000fg-MH; Tue, 13 Oct 2026 07:56:17 -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=wvX8weZue8+YVqFdkS17tNSQTFqlePJvQ9Tpw5kuEEE=; b=l1Xk+0YTGDtT X4iZEnichKSW0WbJHvuBUL39Q9ecL4cmKeiRo0nunbjF87ELV5pdRqcJQNw+4DQtebMF+VCzlRorU JszgLLaLMAGQeKnqdcEqhNjq3VQP6IftruUc3LMPYC9g3W/zkOqIN1Ws2MLHHkZ6f1QM2ZLNVeYgy 2T8stUPDqtcGbfP6JW4Mon7vrZRd06ybMy7pYg/Bg00FWy39u5GhFvUbVmR3ZZeIPl2lw7MkF+34p T47aVMc3iWe1Nl0aK9GvYV1ncHZJif0YLb130PB3HMK38rNpl+CpQEGtl7V61PBANh4IT8Qq2vGay AvT0SxrN/+avMkje5jdb/A==; Date: Tue, 13 Oct 2026 14:56:13 +0300 Message-Id: <86y0c1g6g2.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: (message from Andrew Burgess on Mon, 12 Oct 2026 19:54:27 +0100) Subject: Re: [PATCH 2/5] gdb/doc: fix some incorrect '@table @code' uses References: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: Andrew Burgess > Cc: Andrew Burgess > Date: Mon, 12 Oct 2026 19:54:27 +0100 > > When we have something like this: > > @table @code > @item blah > This is the text. > @end table > > Then the 'blah' text is formatted as '@code{blah}'. We have several > places in the GDB docs where we use '@table @code' when there is a > better alternative than @code. > > I also found a few places where we did something like: > > @table @code > @item @code{blah} > This is the text. > @end table > > In this case the @code around 'blah' is unnecessary, as the table > already applies @code formatting. In this case I've removed the > formatting around the blah text. > > I also spotted this pattern: > > @table @code > @item @var{blah}, some additional explanation. > This is the text. > @end table > > In this case 'blah' is formatted as @var and 'some additional > explanation' is formatted as @code, when I think it is really just > normal text. In this case I change the @code to @asis which will > leave the additional text as-is, i.e. with no special formatting. > > I have not tried to check every @table in the docs. This patch mostly > focused on @code to @kbd, though I did fix up a few other tables where > it was obvious that something else should be applied. However, there > are a lot of tables in the docs, my strategy was to basically spend no > more than a second or two looking at a table, if it wasn't immediately > obvious what change was needed then I left the table as @code. My > hope is that this patch improves the quality of the docs. > --- > gdb/doc/gdb.texinfo | 622 ++++++++++++++++++++++---------------------- > gdb/doc/guile.texi | 6 +- > gdb/doc/python.texi | 16 +- > 3 files changed, 322 insertions(+), 322 deletions(-) Thanks, this is okay. I have a comments: > -@table @code > +@table @asis > @item @var{linenum} > @itemx @var{filename}:@var{linenum} > @itemx -line @var{linenum} There's nothing wrong with having a @var inside @code, we do it in many manuals all the time. The problem happens when there are words in such a table which should neither be in @code nor in @var; but there are no such cases here, AFAICT. OTOH, changing to @asis makes the "@item -line" have the wrong typeface: it should be in @code. So I would leave this case alone. Approved-By: Eli Zaretskii