This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: typos
- From: Martin Jambor <mjambor at suse dot cz>
- To: Veres Lajos <vlajos at gmail dot com>
- Cc: Ondrej Bilka <neleai at seznam dot cz>, gcc at gcc dot gnu dot org
- Date: Wed, 3 Jul 2013 10:44:40 +0200
- Subject: Re: typos
- References: <alpine dot DEB dot 2 dot 00 dot 1307030029470 dot 8850 at citymarket dot hu> <20130703062317 dot GA21956 at popelka dot ms dot mff dot cuni dot cz> <20130703062425 dot GB21956 at popelka dot ms dot mff dot cuni dot cz> <alpine dot DEB dot 2 dot 00 dot 1307030946410 dot 8850 at citymarket dot hu>
Hi,
On Wed, Jul 03, 2013 at 09:55:14AM +0200, Veres Lajos wrote:
> On Wed, 3 Jul 2013, Ondrej Bilka wrote:
>
> > On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote:
> > > Hi,
> > >
> > > I wrote a small misspell finder/fixer script and when I have a little
> > > spare time I clean OS projects with it. (https://github.com/vlajos/misspell_fixer)
> > > I ran it on this repository:
> > > svn://gcc.gnu.org/svn/gcc/trunk
> > > The patch is around 800kb.
> > > What is the best way to handle this modifications?
> > > I mean most of the modifications are in the comments and in the
> > > documentations, but a code-review is needed anyway. The script itself
> > > isn't enough intelligent.
> > > So how could I smooth the way to land these modifications?
>
> > I am writing similar tool, that checks more style issues.
> > I could try to integrate that.
> >
> > My idea is run this as pre-commit hook, separate comments from diff, check it with aspell and print
> > misspelings in standard output so user can filter them.
>
> Classic spellchekers are not really efficient for finding typos in program
> sources. There are too many false positives.
> Anyway can I help somehow?
>
> And if the script will be done you should run it for the whole
> codebase. Otherwise the issues won't be fixed until anybody touches them.
>
perhaps you should be aware that there are people who prefer exactly
that, though the discussions so far have been about
formatting/whitespace problems only. The reason is simpler history
browsing which such changes complicate for little gain (I personally
can cope with it but I see the point).
On the other hand, I think that this would matter much less for lines
where there are only comments. So I'd suggest cherry-picking these
and submitting fixes in them. If the patch is large, split it into a
number of patches for easier review. If there are errors in
identifiers etc. I assume that needs to be handled on case by case
basis, although some related cases can certainly be dealt with
together (and it would upset history a bit so there might even be
opposition to that).
Thanks,
Martin