Karl Fogel wrote:
>> * main.c: Add --xml option to svn_cl__options.
>> (svn_cl__cmd_table): Add svn_cl__xml_opt to log.
>> (main): Add handling for svn_cl__xml_opt.
>
> Typically we say "(svn_cl__options): Add --xml option.".
> This is only a minor nit, however.
>
>> * cl.h: Add svn_cl__xml_opt to enum svn_cl__longopt_t.
>> (svn_cl__opt_state_t): Add xml option.
>
> Same minor nit.
Actually - I went around and investigated this a bit more. I
created the Changelog entries with emacs, so I was wondering why
emacs did not find the name for these two.
It appears that it is using "beginning-of-defun" function to get to
the begging of the defun and then processing the function /
whatever name from there.
And like the documentation of "beginning-of-defun" says:
,----
| Normally a defun starts when there is an char with
| open-parenthesis syntax at the beginning of a line. If
| `defun-prompt-regexp' is non-nil, then a string which matches
| that regexp may precede the open-parenthesis, and point ends up
| at the beginning of the line.
`----
only parenthesis at the beginning of the line are considered.
So, in the files is:
,----
| const apr_getopt_option_t svn_cl__options[] =
| {
`----
versus
,----
| const svn_cl__cmd_desc_t svn_cl__cmd_table[] =
| {
`----
so only the latter case is caught by "beginning-of-defun".
Again, emacs indentation mode itself presents the former of the two
choices as "correct" indentation.
So this is just a very minor issue, but first, how should the
indentation be in variables that are assigned lists - and secondly,
should the (): format of changes be used for functions and
structures only - or also for variables, enums, everything?
>> + /* The header generation is commented out because it might not
>> + be certain that the log messages are indeed the advertised
>> + encoding, UTF-8. The absence of the header should not matter
>> + to people processing the output, and they should add it
>> + themselves if storing the output as a fully-formed XML
>> + document. */
>> + /* <?xml version="1.0" encoding="utf-8"?> */
>
> Interesting thought! I guess this is the best solution we can do,
> isn't it? Oh well.
Well the case runs a bit deeper here. I guess the real question is
that are log messages, by definition, text - or are they a bunch of
binary bytes? If they are text, then they probably would have a
character set - and a language, like someone on IRC pointed out -
and those would need to be handled somehow if they are dumped into
XML. On the other hand, if they are bytes, then they really cannot
be included in the XML as text, regardless of the escaping of
characters - but encoded in some binary format.
But I guess these issues can wait until i18n is properly underway.
> I'd like to just apply this, with the tweaks above, and then do the
> interface fix. No need to resubmit, I'll take care of it. Thanks for
> the patch.
Very nice, thanks.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 2 04:11:35 2002