Hey, I don't mean to cause a stir, but for me TextMate's code folding is generally just broken. I've spent a lot of time lately working on Jinja2 templates and it just doesn't handle them well at all and sometimes code is removed accidentally. I've had the same thing happen with messier PHP templates, etc.
Is there a way to just turn this off? Toggling folding levels at "All Levels" does not address the problem, some "weirder" blocks of templates (and other bits of messier code that I, of course, didn't write) still remain folded weirdly.
Thanks,
On 6 Oct 2014, at 18:36, Wells Oliver wrote:
[…] Is there a way to just turn this off? Toggling folding levels at "All Levels" does not address the problem, some "weirder" blocks of templates (and other bits of messier code that I, of course, didn't write) still remain folded weirdly.
Select All (⌘A), delete (⌫), and undo (⌘Z). That should “reset” metadata attached to the text buffer (such as folded ranges).
If you, after this, do not want the arrows in the gutter, that allow you to fold text, you can disable the folding settings.
If you are on the nightly builds, you can use Select Bundle Item… (⌃⌘T) and switch to settings (⌘}), then enter “folding” and you will see the folding patterns (for the file type of the current file). Selecting any of them will open that item in the bundle editor where you can uncheck the “Enable this item” (and then save the change with ⌘S).
On Oct 7, 2014, at 5:30 AM, Allan Odgaard mailinglist@textmate.org wrote:
Select All (⌘A), delete (⌫), and undo (⌘Z). That should “reset” metadata attached to the text buffer (such as folded ranges).
That's good, but wouldn't it be better to find out what's going wrong with code folding? I've never seen any of these munging issues myself. m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On 7 Oct 2014, at 17:07, Matt Neuburg wrote:
On Oct 7, 2014, at 5:30 AM, Allan Odgaard mailinglist@textmate.org wrote:
Select All (⌘A), delete (⌫), and undo (⌘Z). That should “reset” metadata attached to the text buffer (such as folded ranges).
That's good, but wouldn't it be better to find out what's going wrong with code folding? I've never seen any of these munging issues myself. m.
If the file is changed by another application then the folded ranges (stored as an extended file attribute) will no longer point to the correct ranges. As long as the file is only changed by TextMate, or any changes made outside TextMate also cause the com.macromates.folded extended attribute to be dropped, then there shouldn’t be any issues.
On Oct 7, 2014, at 10:32 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 7 Oct 2014, at 17:07, Matt Neuburg wrote:
On Oct 7, 2014, at 5:30 AM, Allan Odgaard mailinglist@textmate.org wrote:
Select All (⌘A), delete (⌫), and undo (⌘Z). That should “reset” metadata attached to the text buffer (such as folded ranges).
That's good, but wouldn't it be better to find out what's going wrong with code folding? I've never seen any of these munging issues myself. m.
If the file is changed by another application then the folded ranges (stored as an extended file attribute) will no longer point to the correct ranges. As long as the file is only changed by TextMate, or any changes made outside TextMate also cause the com.macromates.folded extended attribute to be dropped, then there shouldn’t be any issues.
That explains why I see that occasionally, I tend to use git from the command line and switch branches frequently.
IIRC TextMate does see if a file changed and reloads it, couldn't it figure out that folds no longer match? Maybe the stored fold data could be somehow fingerprinted with some file data? Or before re-applying the folding TextMate could check if the stored fold locations match actual fold candidates in the current text?
Gerd
On 7 Oct 2014, at 17:39, Gerd Knops wrote:
IIRC TextMate does see if a file changed and reloads it, couldn't it figure out that folds no longer match?
When reloading an open file, it shouldn’t cause issues.
Maybe the stored fold data could be somehow fingerprinted with some file data? Or before re-applying the folding TextMate could check if the stored fold locations match actual fold candidates in the current text?
I added a CRC 32 check when reading the folding data so that if the content has changed, the folding data will be ignored.
Not sure this will do anything for you though, as Git normally write new files, so it does not inherit the extended attributes from the previous content.
Perhaps there are cases where this is not the case, but I tested checkout plus stash and in both cases, the extended attributes were lost when Git made changes to the content.
Might be irrelevant, but all of my code is in Dropbox, and I work from various locations. I doubt that would have an effect on the metadata files, presumably stored on the local drives, but I thought I'd mention it.
On Tue, Oct 7, 2014 at 9:35 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 7 Oct 2014, at 17:39, Gerd Knops wrote:
IIRC TextMate does see if a file changed and reloads it, couldn't it
figure out that folds no longer match?
When reloading an open file, it shouldn’t cause issues.
Maybe the stored fold data could be somehow fingerprinted with some file
data? Or before re-applying the folding TextMate could check if the stored fold locations match actual fold candidates in the current text?
I added a CRC 32 check when reading the folding data so that if the content has changed, the folding data will be ignored.
Not sure this will do anything for you though, as Git normally write new files, so it does not inherit the extended attributes from the previous content.
Perhaps there are cases where this is not the case, but I tested checkout plus stash and in both cases, the extended attributes were lost when Git made changes to the content.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 7 Oct 2014, at 18:37, Wells Oliver wrote:
Might be irrelevant, but all of my code is in Dropbox, and I work from various locations. I doubt that would have an effect on the metadata files, presumably stored on the local drives, but I thought I'd mention it.
If DropBox synchrnoizes file content but not extended attributes, then that would be a very likely explanation of your issues.
So with the CRC32 check your issue should be gone (starting with next build), so I would recommend you delay disabling the folding settings.
-
Allan Odgaard -
Gerd Knops -
Matt Neuburg -
Wells Oliver