From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7116 invoked by alias); 18 Apr 2007 10:22:58 -0000 Received: (qmail 6967 invoked by uid 22791); 18 Apr 2007 10:22:57 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Apr 2007 11:22:54 +0100 Received: from farnswood.snap.net.nz (78.62.255.123.dynamic.snap.net.nz [123.255.62.78]) by viper.snap.net.nz (Postfix) with ESMTP id 6C4983D9E4C; Wed, 18 Apr 2007 22:22:50 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 3721A627ED; Wed, 18 Apr 2007 11:20:35 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17957.61682.569532.764026@farnswood.snap.net.nz> Date: Wed, 18 Apr 2007 10:37:00 -0000 To: Vladimir Prus Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: Ping: frozen variable objects In-Reply-To: <200704180938.17763.vladimir@codesourcery.com> References: <200703251351.43195.vladimir@codesourcery.com> <17954.4745.780804.328395@farnswood.snap.net.nz> <200704180938.17763.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.0.97.5 X-IsSubscribed: yes 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 X-SW-Source: 2007-04/txt/msg00278.txt.bz2 > > > It's Eli who decides, but having -var-update reference -var-set-frozen > > > which in turn references -var-update seems too complicated, and > > > shouldn't be necessary if there was a natural flow. > > > > I'm afraid I wasn't following this sub-thread closely enough, so > > forgive me, Vladimir, if I ask what was already said: could you please > > explain the rationale for your change of the anchors in this patch? > > You've asked to add a reference to -var-update. There was already > -var-update anchor. However, that anchor was pointing in the middle of > -var-update documentaiton, so following the reference would land the reader > at list of some attributes, which would be confusing. And it seems that > calling anchor for entire -var-update docs as -var-update is more reasonable > then using -var-update anchor for the list of fields output by -var-update. > > Does this clarify things? For this case, I suggested using the existing pxref with two arguments (three might be better still). However, you're now adding another pxref and anchor, and the point I tried to make above was that it shouldn't be necessary to have circular references within a single node. (Actually, as a rule of thumb, I would say it's a good idea not to have references within one node at all, as it's not unreasonable to expect the reader to, at least, skip read the whole node. If it is unresonable then the node is probably too long. However, I'm not suggesting to take the first one out too.) -- Nick http://www.inet.net.nz/~nickrob