(cc-ing dev list -- hope you don't mind)
On 22.01.2010 10:28, Yuki KODAMA wrote:
> On Thu, Jan 21, 2010 at 17:59, Adrian Buehlmann <adr...@cadifra.com> wrote:
>> (cc-ing Steve)
>>
>> On 21.01.2010 07:40, Yuki KODAMA wrote:
>>> On Tue, Jan 19, 2010 at 05:01, Adrian Buehlmann <adr...@cadifra.com> wrote:
>>>> On 18.01.2010 20:09, Yuki KODAMA wrote:
>>>>> On Tue, Jan 19, 2010 at 03:55, Adrian Buehlmann <adr...@cadifra.com>
>>>>> wrote:
>>>>>> On 15.01.2010 16:25, Adrian Buehlmann wrote:
>>>>>>> I'm contemplating to fix issue 867 [1] with the following patch.
>>>>>>
>>>>>> I've pushed it to default as
>>>>>> http://bitbucket.org/tortoisehg/stable/changeset/782189b23886/
>>>>>
>>>>> Ahhh, sorry Adrian, I entirely missed this post.
>>>>> I'll test this in next few days and report the result.
>>>>>
>>>>
>>>> No problem and thanks in advance for testing.
>>>>
>>>> It will probably be in the next nightly (in case Steve builds one
>>>> tonight).
>>>>
>>>
>>> As the result, renewed shellext works well.
>>> Japanese menu labels are shown correctly, and other commands of shellext
>>> ("Add Files...", "Remove Files...", ...) also work without any problem.
>>>
>>
>> Thanks for testing.
>>
>> 782189b23886 didn't touch context menu -- only overlay handler.
>>
>> My concern was about filenames. As I don't try to version control files with
>> names that are not ASCII with mercurial, I'm not affected by 782189b23886
>> myself.
>>
>> I was more concerned about people using such special things like
>> Win32mbcs extension or non-ASCII filenames in general.
>
> Okay, I'll test again with a focus on non-ASCII chars and win32mbcs later.
>
> BTW, I forgot to report, there is small issue on icon overlay.
> Please see attached screenshot; you can see 5 entries and 1 selected file
> in Windows Explorer. The selected file is versioned (clean file), but THG
> doesn't show any overlay icon.
>
> This problem is called "dame moji" (in Japanese).
> The name of selected file contains 3 chars (except file extension part) and
> last char consists of 2 bytes: "95" and "5C" (in ASCII).
> You know "5C" is backslash char, so THG (or HG) misunderstand it as
> directory separator or character escaping.
>
> By win32mbcs, TortoiseHg dialogs work fine and clear "dame moji" problem,
> but shellext doesn't.
>
> This problem has been confirmed since 0.8, not recently.
> I suppose you are difficult to reproduce and test this problem,
> so I'll try to fix this if possible.
>
Thanks Yuki. Interesting read.
Might be a good idea to note the "dame moji" problem in an issue on bitbucket
(in case there isn't already one).
Since I don't use win32mbcs and don't understand any of those languages
that make use of it I'm indeed the very wrong person to improve things on that
front.
In fact, I was assuming that non-western users were happy with the overlays,
(or at least they didn't yell at us) since I didn't read (or at least was not
aware)
of problems reported. Seems I was wrong here.
By committing 782189b23886 I didn't know if there would be additional problems
due to the fact that I simply inserted calls to Windows API functions
transforming
all filenames to lowercase before processing them in the overlay handler, so
that
the equality tests for filenames inside the overlay handler could stay as they
are.
I admit I have no idea what the exact lowercase transformation function
is Windows is using to compare filenames for equality. All I find they
write about filenames on Windows [1] is:
Do not assume case sensitivity. For example, consider the names OSCAR,
Oscar, and oscar to be the same, even though some file systems (such as
a POSIX-compliant file system) may consider them as different. Note that
NTFS supports POSIX semantics for case sensitivity but this is not the
default behavior. For more information, see CreateFile.
[1] http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
I understand that splitting filenames into path components (at the backslash
character) is a fundamental problem in the overlay handler. We have already
touched this before with the work started by Stefan Rusek (which got right into
the middle of that recent general overlay handler crisis we had, unfortunately).
The problem already exits in the .hg/dirstate file written by mercurial, which
the
overlay handler is reading directly. It seems the win32mbcs extension is
affecting how filenames are written into .hg/dirstate as well.
Seems quite complicated to tackle all these i18n things on filenames.
I openly admit that I'm not exactly that motivated to invest much time
on that front, since I know it is a fundamental problem in Mercurial
anyway and I for myself as a software developer am perfectly happy
using Mercurial with plain English filenames only. As a German speaking
user (native Swiss-German) I don't even have a desire to try using
umlauts in filenames.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Tortoisehg-develop mailing list
Tortoisehg-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
