Visual Studio integration
rbraga at gmail.com
Sun Mar 18 01:42:03 GMT 2007
"reply to" bzr list fail :)
On 3/17/07, Alexander Belchenko <bialix at ukr.net> wrote:
> -----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  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
> -----END PGP SIGNATURE-----
More information about the bazaar