Jeff King writes:
> On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
>
>> Erik Faye-Lund writes:
>>
>> > However, since git only looks at one byte at the time for
>> > short-options, it ends up reporting a partial UTF-8 sequence
>> > in such cases, leading to corruption of the ou
On Mon, Feb 11, 2013 at 6:19 PM, Jeff King wrote:
> On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
>
>> Erik Faye-Lund writes:
>>
>> > However, since git only looks at one byte at the time for
>> > short-options, it ends up reporting a partial UTF-8 sequence
>> > in such cases, l
On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
> > However, since git only looks at one byte at the time for
> > short-options, it ends up reporting a partial UTF-8 sequence
> > in such cases, leading to corruption of the output.
>
> Isn't it a workab
On Mon, Feb 11, 2013 at 6:07 PM, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> However, since git only looks at one byte at the time for
>> short-options, it ends up reporting a partial UTF-8 sequence
>> in such cases, leading to corruption of the output.
>
> Isn't it a workable, easier and
Erik Faye-Lund writes:
> However, since git only looks at one byte at the time for
> short-options, it ends up reporting a partial UTF-8 sequence
> in such cases, leading to corruption of the output.
Isn't it a workable, easier and more robust alternative to punt and
use the entire ctx.argv[0] a
On 11.02.13 17:36, Erik Faye-Lund wrote:
> On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen wrote:
>> On 11.02.13 14:34, Erik Faye-Lund wrote:
>>> Even though parse-options doesn't support UTF-8 switches (which
>>> makes sense; non-ascii switches would be difficult to enter on
>>> some keyboa
On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen wrote:
> On 11.02.13 14:34, Erik Faye-Lund wrote:
>> Even though parse-options doesn't support UTF-8 switches (which
>> makes sense; non-ascii switches would be difficult to enter on
>> some keyboard layouts), it can be useful to report incorre
On 11.02.13 14:34, Erik Faye-Lund wrote:
> Even though parse-options doesn't support UTF-8 switches (which
> makes sense; non-ascii switches would be difficult to enter on
> some keyboard layouts), it can be useful to report incorrectly
> entered UTF-8 switches to make the output somewhat less ugly
On Mon, Feb 11, 2013 at 3:05 PM, Matthieu Moy
wrote:
> Erik Faye-Lund writes:
>
>> But isn't UTF-8 constructed to be very unlikely to clash with existing
>> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
>> simply writes the byte as a hex-tuple?
>
> If it's non-ascii and n
Erik Faye-Lund writes:
> But isn't UTF-8 constructed to be very unlikely to clash with existing
> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
> simply writes the byte as a hex-tuple?
If it's non-ascii and non-UTF-8, I think you'd want to display the byte
as it is, beca
On Mon, Feb 11, 2013 at 2:43 PM, Matthieu Moy
wrote:
> Erik Faye-Lund writes:
>
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -3,6 +3,7 @@
>> #include "cache.h"
>> #include "commit.h"
>> #include "color.h"
>> +#include "utf8.h"
>>
>> static int parse_options_usage(struct parse_opt_c
Erik Faye-Lund writes:
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -3,6 +3,7 @@
> #include "cache.h"
> #include "commit.h"
> #include "color.h"
> +#include "utf8.h"
>
> static int parse_options_usage(struct parse_opt_ctx_t *ctx,
> const char * const *us
Even though parse-options doesn't support UTF-8 switches (which
makes sense; non-ascii switches would be difficult to enter on
some keyboard layouts), it can be useful to report incorrectly
entered UTF-8 switches to make the output somewhat less ugly
for those of us with keyboard layouts with UTF-8
13 matches
Mail list logo
