This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] microMIPS support


> Date: Fri, 27 Apr 2012 18:45:56 +0100
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
> CC: <gdb-patches@sourceware.org>
> 
> On Thu, 26 Apr 2012, Eli Zaretskii wrote:
> 
> > > > Index entries should all start with lower-case letters, otherwise the
> > > > index sorting is unpredictable (in non-US locales).
> > > 
> > >  OK, but is that a problem?  If a foreign locale uses a different sorting 
> > > order, then it's exactly what the user of that locale expects, isn't it?  
> > 
> > Not if the Info files are then put into a release tarball and
> > distributed worldwide.
> 
>  So may I suggest fixing the release process to use the intended locale 
> instead (C or en_US, or whatever)?

I don't know enough about the GDB releases to tell if this is
practical.

Anyway, I try to keep all index entries start with a lower-case
letter.  This is more reliable than imposing a certain locale on the
environment where the release tarballs are made.

>  I'll see what I can do about it then, if that satisfies you.  However I 
> still have troubles to accept this requirement.  So if the first word had 
> to be a city or person's name, you'd demand it to start with a small 
> letter too?

We don't have person names or cities in the GDB manual.  A manual that
has many of these in the indices should probably consistently use
capitalization of the first word in the index entries.

> I just don't buy it, sorry, there's something wrong with the process
> if you must make such requirements.

I don't understand why it matters to you so much, sorry.

> > >  As the platform maintainer I can offer you to review the whole manual and 
> > > adjust all the instances of "MIPS" (plus any variants and any related 
> > > acronyms I'll spot) as a separate change.  I think it will be more 
> > > productive and not really a lot of effort.
> > 
> > I will do that when I have time, thanks.
> 
>  I offered you mine instead, but I won't insist.

Sorry, my misunderstanding.  If you want to do it, I'd appreciate
that.

>  I have regenerated both paragraphs added with the tag applied and 
> actually I agree -- and contrary to documentation it works just fine for 
> microMIPS.  So I decided to follow your suggestion even though @acronym is 
> a misnomer here ("MIPS" and all the derivatives are really the same class 
> of names as "Intel", or "Linux", or "NetBSD" are -- it's just that their
> capitalisation is weird).  You've convinced me.

Thank you.

> > > > I didn't ask you to revamp the entire section.  Even if the rest of
> > > > the section will never be fixed, it still makes sense to not increase
> > > > the amount of node-less subsections.
> > >
> > >  It makes no sense to me not to revamp the entire section
> > 
> > I won't object if you do revamp it, if you feel like it.  But I will
> > approve the patch even if you don't, because I think it's unfair to
> > ask you to fix what you didn't break.
> 
>  I appreciate that, but likewise it's my right to offer you doing it.

I accept the offer, thanks.

> Do you really like the outcome, like an empty "ARM" subsection with
> a lone reference to its "Breakpoint Kinds" subsubsection?  I find it
> an unnecessary hassle to go through when reading the manual.

There's no need to have empty subsections or nodes.  Please delete
those empty nodes.  All I asked was to have a node where you have a
subsection with some content.  There's no need to introduce
subsections or node with no content at all.

> I hope you can accept these changes.

I accept, but please remove the empty subsections/nodes.

Thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]