Re: svn commit: r13112 - in trunk/subversion: libsvn_fs_base libsvn_subr

> dionisos@tigris.org writes:
>
> > Author: dionisos
> > Date: Tue Feb 22 12:07:20 2005
> > New Revision: 13112
>
> > --- trunk/subversion/libsvn_subr/utf.c (original)
> > +++ trunk/subversion/libsvn_subr/utf.c Tue Feb 22 12:07:20 2005
> > @@ -544,8 +540,8 @@
> > (unsigned char)last[i]),
> NULL);
> >
> > return svn_error_createf (APR_EINVAL, NULL,
> > - _("Valid UTF-8 data\n(hex:%s)\n"
> > - "followed by invalid UTF-8
> sequence\n(hex:%s)"),
> > + _("Valid UTF-8 data (hex:%s)"
> > + "followed by invalid UTF-8 sequence
> (hex:%s)"),
> > valid_txt, invalid_txt);
> > }
>
> Your change is not really compatible with the comment in the code:
>
> /* We will display at most 24 valid octets (this may split a leading
> multi-byte character) as that should fit on one 80 character line. */
>
> While I would agree that one line error messages are generally better,
> I think this one might be an exception. Is there any particular
> reason to avoid "\n", i18n perhaps?

Our i18n code compensates for the problem that some platforms use CRLF, so
that's not really the reason. \n characters don't go well with GUI and other
applications which don't have 80 character wide displays.

Potentially many of our error strings surpass 70 or 80 characters as very
many will have filenames inserted into the string.

Also, there currently still is a problem with our md5 mismatch error
strings: many of them use \n-s to allign the md5s, but on GUIs which *do*
wrap lines nicely, there still is no guarantee of fixed width fonts...

Altogether, the entire keep-errors-below 80 characters idea may just not be
as viable as it looks. :-(

bye,

Erik.

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org