Hi,
I've had a look for this in the archives but no mention of it, so here's a very minor bug I just found:
Basically, TextMate will garble its caret bookmark file attribute whenever column == 0 && line == 0. When saving any file with the caret in this position, the resulting attribute always read like this:
com.macromates.caret: 0000 78 9C AB E6 52 00 82 E4 FC 9C D2 DC 3C 05 5B 05 x...R.......<.[. 0010 03 6B 30 3F 27 33 2F 15 C2 AB 05 00 8B 99 08 1D .k0?'3/.........
When saving the file with the caret in any other position, the attribute saves normally:
com.macromates.caret: { column = 0; line = 1; }
Tested & reproduced using TextMate 1.5.8 (build 1498) on an Intel Core 2 Duo MacBook running OS X 10.5.5 (9F33).
I hope that's enough information to identify the offending code -- keep up the good work, it's a great app!
-- Nick
On 12 May 2009, at 09:52, Nick Wright wrote:
Basically, TextMate will garble its caret bookmark file attribute whenever column == 0 && line == 0 [...]
Actually, it gzips the data.
The reason is that extended attributes have an (undocumented) size limit, so TextMate will compress its values whenever the compressed size is smaller than the actual size — I don’t like this, but I did run into the size limit for both bookmarks and folding markers, and since the length is undocumented, I chose to compress whenever it gave a size reduction.
Basically, TextMate will garble its caret bookmark file attribute whenever column == 0 && line == 0 [...]
Actually, it gzips the data.
The reason is that extended attributes have an (undocumented) size limit, so TextMate will compress its values whenever the compressed size is smaller than the actual size — I don’t like this, but I did run into the size limit for both bookmarks and folding markers, and since the length is undocumented, I chose to compress whenever it gave a size reduction.
Ah OK, that makes sense. What is the size limit, out of interest?
-- Nick
On 20 May 2009, at 11:58, Nick Wright wrote:
[...] The reason is that extended attributes have an (undocumented) size limit [...]
Ah OK, that makes sense. What is the size limit, out of interest?
Ehm… the size limit is undocumented :) It’s actually not documented at all, that there is such size limit. I think it is related to the current implementation, using spare space in the inode for extended attributes or similar, so I didn’t do any practical findings, when I played with this.
[...] The reason is that extended attributes have an (undocumented) size limit [...]
Ah OK, that makes sense. What is the size limit, out of interest?
Ehm… the size limit is undocumented :) It’s actually not documented at all, that there is such size limit. I think it is related to the current implementation, using spare space in the inode for extended attributes or similar, so I didn’t do any practical findings, when I played with this.
So, a _random_ undocumented limit..? Nice :-) I probably won't be the first (nor the last), but I forwarded a bug report to Apple via their feedback form.
Thanks for getting back to me.
-- Nick
-
Allan Odgaard -
Nick Wright