Alexander Belchenko wrote:
> Jason Spashett пишет:
>
>> Yes perhaps it cannot be fixed.
>>
>
> No, it can be fixed, just need to add more code to bzr command-line
> parsing functions. If you willing to fix this I can guide you.
>
>
Yes, I can have a look at this, could you describe briefly what it may
require? What I wrote in the bug report wasn't a good way?
>> How come we need to call the windows api
>> to get unicode arguments?
>>
>
> 1) We need to get actual unicode command-line because python tends to
> encode arguments in user encoding, effectively hiding from us real
> unicode. We had bug report about this.
>
>
Understood.
> 2) Starting from 2.1 bzr parsing raw unsicode command-line string to be
> able imitate glog expansion as on Linux, e.g.
>
> bzr status *.txt
>
> will show you status only for text files in the current directory.
>
Not sure why unicode is needed for (2), but it doesn't matter. Obviously
there is a reason.
Hello Alexander,
Alexander Belchenko wrote:
> Jason Spashett пишет:
>
>> Yes perhaps it cannot be fixed.
>>
>
> No, it can be fixed, just need to add more code to bzr command-line
> parsing functions. If you willing to fix this I can guide you.
>
>
Yes, I can have a look at this, could you describe briefly what it may
require? What I wrote in the bug report wasn't a good way?
>> How come we need to call the windows api
>> to get unicode arguments?
>>
>
> 1) We need to get actual unicode command-line because python tends to
> encode arguments in user encoding, effectively hiding from us real
> unicode. We had bug report about this.
>
>
Understood.
> 2) Starting from 2.1 bzr parsing raw unsicode command-line string to be
> able imitate glog expansion as on Linux, e.g.
>
> bzr status *.txt
>
> will show you status only for text files in the current directory.
>
Not sure why unicode is needed for (2), but it doesn't matter. Obviously
there is a reason.
Regards,
Jason