Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] microMIPS support
Date: Fri, 27 Apr 2012 18:24:00 -0000	[thread overview]
Message-ID: <83y5ph6nqj.fsf@gnu.org> (raw)
In-Reply-To: <alpine.DEB.1.10.1204262305130.19835@tp.orcam.me.uk>

> 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.


  reply	other threads:[~2012-04-27 18:20 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 21:18 Maciej W. Rozycki
2012-04-25  6:20 ` Eli Zaretskii
2012-04-26 13:54   ` Maciej W. Rozycki
2012-04-26 14:14     ` Eli Zaretskii
2012-04-26 18:03       ` Maciej W. Rozycki
2012-04-26 20:39         ` Eli Zaretskii
2012-04-27 18:16           ` Maciej W. Rozycki
2012-04-27 18:24             ` Eli Zaretskii [this message]
     [not found]               ` <alpine.DEB.1.10.1204302334520.19835@tp.orcam.me.uk>
2012-05-02 16:39                 ` Eli Zaretskii
2012-05-17 15:07                   ` Maciej W. Rozycki
2012-05-17 16:10                     ` Eli Zaretskii
2012-05-18 23:13                       ` Maciej W. Rozycki
2012-05-19  8:20                         ` Eli Zaretskii
2012-04-25 13:13 ` Yao Qi
2012-04-25 15:57   ` Maciej W. Rozycki
2012-04-25 15:54 ` Joel Brobecker
2012-04-25 17:18   ` Maciej W. Rozycki
2012-04-25 18:12     ` Joel Brobecker
2012-04-25 18:27       ` Maciej W. Rozycki
2012-04-26 18:38 ` Jan Kratochvil
2012-04-26 19:04   ` Maciej W. Rozycki
2012-04-26 19:29     ` Jan Kratochvil
2012-04-26 21:59       ` Maciej W. Rozycki
2012-04-27  7:11         ` Jan Kratochvil
2012-04-27 15:14           ` Maciej W. Rozycki
2012-04-27 15:29             ` Pedro Alves
2012-04-27 15:46               ` Maciej W. Rozycki
2012-04-27 15:54             ` Tom Tromey
2012-05-18 23:53     ` Maciej W. Rozycki
2012-05-18 21:32 ` [PATCH] microMIPS support (Linux signal trampolines) Maciej W. Rozycki
2012-05-18 22:25   ` Mark Kettenis
2012-05-21 14:33     ` Maciej W. Rozycki
2012-06-11 10:32       ` [PING][PATCH] " Maciej W. Rozycki
2014-09-28 11:12       ` [PATCH] " Maciej W. Rozycki
2014-10-06  0:46         ` [PING][PATCH] " Maciej W. Rozycki
2014-10-13 12:24           ` [PING^2][PATCH] " Maciej W. Rozycki
2014-10-20 17:01             ` [PING^3][PATCH] " Maciej W. Rozycki
2014-11-03 16:04               ` [PING^4][PATCH] " Maciej W. Rozycki
2014-11-16  8:58         ` [PATCH] " Joel Brobecker
2014-12-03 21:00           ` Maciej W. Rozycki
2012-05-18 23:47 ` [PATCH] microMIPS support Maciej W. Rozycki
2012-05-19  8:52   ` Eli Zaretskii
2012-05-22  0:07     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y5ph6nqj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox