Visual Studio integration

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel пишет:
> Klaus Hartke wrote:
>> John Arbash Meinel wrote:
>>> You can't get feedback on something people can't see. :)
>> I've put up a few screenshots [1] showing most of the features currently
>> supported by the add-in:
> 
> 
> I'm quite impressed that you've put together so much so quickly. Which
> route did you end up going? (High level embedding, or calling out to a
> bzr process).
> 
> Also, I couldn't help but notice here:
> http://www.informatik.uni-bremen.de/~hartke/bzr/bzr-vsaddin-4.png
> 
> There seem to be some odd characters. Is this an incorrect character set
> bug? It seems to be a utf-8 byte order mark, which is confusing the diff
> tool.
> 
> A quick check says that UTF8_BOM == '\xef\xbb\xbf' and that:
> 
>>>> print '\xef\xbb\xbf'.decode('cp1252')
> 
> 
> Anyway, I'm not sure if you want to do any different. But obviously the
> file is supposed to be in UTF8 encoding, and the diff is being displayed
> in MS's default "cp1252" encoding (it could also be iso-8859-1, ie
> latin-1. I'm not sure what the specific differences are for cp1252). It
> is a minor thing here, but if you had any real unicode in the file, it
> would all come out as garbage. (Case in point, å => Ã¥ if you use cp1252
> instead of utf8)
> 
> We (bzr) has generally taken the stance of not trying to do anything
> special with the *contents* of files. But it just makes me think...
> 
> For example, to properly display the diff, you need to know that the
> file is utf-8 encoded, which is hinted by the UTF8_BOM at the beginning.
> (It isn't really a byte-order-mark, but it fits a similar purpose as the
> UTF16 byte-order-mark).
> 
> Anyway, if the first line of the file wasn't modified, then you would
> potentially not see that line of the output. So how would a diff tool
> know what encoding to display it in?

I did work on similar problem for bzr-gtk diff, but it that case I need to solve
reverse problem: decode content of file to unicode and convert it to utf-8,
because GTK want utf-8. I did this in the simple approach: assume that system
locale encodings is the same as user data encodings. It helps in many cases.

> It brings up an old request to be able to mark the encoding for files as
> bzr metadata. I'm still not sure that we want to encode/decode the
> contents of files (modifying people's data in flight just feels like a
> good way to break stuff for them). But having a way to record it would
> be helpful for situations like this.

Yes, this is why I think we need to have ability to store such info.

[µ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/JbAzYr338mxwCURAuaXAJ4tPUx589vXc7a/ar6g+vaW0PLEnACfWOoD
35ulLzpPfgXH31/T0IHzpSc=
=9k+k
-----END PGP SIGNATURE-----