On Sun, 2003-06-22 at 06:56, Branko Èibej wrote:
> > 1. Make svn_handle_error() only print the generic error text if the
> > message field is NULL.
> >
> I wonder if that's overkill? We already hide the generic message for
> wrapped errors that have the same error code.
Even for the simplest case of a single-level error, the two messages are
generally redundant. For instance:
svn: Item is out of date
svn: Item 'foo.c' is out of date.
> > 2. Make svn_handle_error() word-wrap the error field to 70 columns
> > (or to the display width minus some margin, but that might be too
> > irritating to handle portably);
> Yes.
Actually, I'm currently thinking no, because:
* Word-wrapping internationalized text is hard.
* Determining the appropriate display width is hard.
* Word-wrapping variable error text such as filenames and URLs is
probably bad; if those are long, better to display long lines.
* For long explanatory error messages, we can use internal newlines at
some reasonable width (probably whatever makes the C code look nice,
which would tend to be in the 50-70 column range). If that's
narrower than the display device can handle, it will still look
okay. This is assuming internal newlines are okay, of course.
> > also allow the error message to
> > contain newlines for those rare cases when a message needs line
> > structure,
> >
> Plese no. Think of what happens when a GUI tries to display this message.
Of course I thought of that. The GUI may have to go to extra work just
as svn_handle_error() would have to, but I don't see why a GUI is in any
worse position than the command-line client is.
> > such as when it provides an example command. All
> > output lines will begin with "svn: ", of course.
> This can easily be achieved by wrapping svn_error_t's. Since the generic
> error code is already hidden in this case, you'll get exactly what you want.
But now the error is skewed from a machine-recognition perspective.
Does it make sense for code to see six chained SVN_ERR_RA_OUT_OF_DATE
errors because we happened to want six lines of error text? In my
world, chained errors reflect a high-level to low-level flow of error
information, not merely an addition of lines of error text.
> > I don't think any of these guidelines should prevent problems for
> > localization.
> >
> They might; sometimes the order of sentences differs from language to
> language. So the guideline should be that when you use wrapped messages
> (i.e., where line structure is important), these should only contain
> examples (complete commands, or single URLs/paths); and they should
> always be the last thing to be printed.
I don't see how internal line structure hurts localization, even if the
local language requires a different order of sentences. It just means
you have to localize a string containing newline characters; you can
change the order of sentences just fine.
> > The guidelines may also want to say something about what you
> > should think about when you're writing an error message for an
> > error which is going to be wrapped around a lower-level error.
> > Should the programmer be able to expect that the order of error
> > messages in this case? Are we displaying them in the right order
> > currently? (Right now we start at the highest level and
> >
> And what? :-)
And apparently fail to finish editing that paragraph. :) "... and go
down.)"
> > There's also something screwy about the interaction between
> > svn_strerror() and handle_error(). It looks like handle_error()
> > is assuming that we should convert Subversion error messages from
> > UTF8 to native but not APR error messages, which leads to the
> > terrifying conclusion that svn_strerror() is returning UTF8 text
> > for Subversion error codes and native text for APR error codes.
> > I'm not sure how to sort this out.
> Short of getting some I18N rules into APR, I don't believe it's
> possible.
Well, we could assume that APR errors are in the native character set
and convert them to UTF-8, although that might complicate the reporting
of apr_iconv errors.
> It would be enough to declare (for now) that apr_strerror
> returns ASCII-only strings, in which case they're automagically UFF-8,
> too. No, I have no idea what happens in an EBCDIC environment then.
I've never quite figured out whether C string literals are supposed to
be in the native character set or if we can assume that they're in ASCII
(in which case they're UTF-8). I suppose the conditional in
handle_error() is there so that (again) we can report apr_iconv errors
without running into a recursive failure.
> > Finally, there's no need for handle_error() to be recursive; in C
> > code, it's usually clearer to iterate over a linked list with a
> > for loop.
> Just goes to show that it was written by people who'd at one time
> contemplated writing SVN in lisp. :-)
Yeah, I figured as much. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 22 15:20:50 2003