Sublime Forum

Folding, Again


I have read the “Folding” discussion re ST thoroughly, as well as having spent hours and hours upon trying out the current state of affairs, and I’m so seriously underwhelmed that currently, I’m one of ST’s users - I’ve been for some days now, since, indeed, ST’s font rendering on screen is spectacular, as I have said in my first post here, this one’s my second one, since my first ST’s “design” preoccupation - who click away the “Buy” reminders, instead of otherwise happily buying indeed: No other editor out there in which coding is as “happy a coding” out there, and I own a lifetime license of EmEditor, and others, but core functionality MUST be there before I (then happily, again) open my purse.


First of all, “Code Folding” belongs to “View”, not to “Edit”: this is clear as day, no “preference”, no discussion allowed. (But I would give a heck about where to find the sub-menu IF by the respective key = shortcut assignments, the respective functionality was available…)


Some user, in 2014, to the question, “Can ST fold XML tags?” ( Can ST fold XML tags? ) - well, I was going to copy-n-paste the respective link now, but you have included it already - I like that a lot, albeit you should have put it into the clipboard, formatted as I have reformatted it above! :wink: -, answered:

“Sublime folds on an indent basis. So if fold doesn’t play nice, maybe you need reformat the code?”

Oh, well! And in the meantime, exactly 9 years have passed since then, ST users have constantly been complaining about even the “folder by tag” functionality, to no avail, and there have been allegations that perhaps the “folder” developer may have left the team, and reminders that folding improvements are quite high on the team’s agenda: well…

And to say it all, from some other screenshots, it seems that once, (now quite expensive but otherwise incredibly good) EmEditor (which function-wise might be considered today’s absolute standard in many respects), had had the very best folding, but then, that folding over there seems to have been “simplified” in-between (?), and I haven’t been able to get any worthwhile “tag” folding out of what I’ve found about folding over there currently, but whilst that may be just “my bad”, ST is, in spite of its overly preposterous name (… “Directory Opus”, anyone, and which is far from being as good as they think it is?), oh so pleasant to the eyes indeed, and when writing/coding 70 and more hours a week, “looks” are are a very valid criterion, even considered from a physiological point of view…


ST’s folding by indentation works fine BUT forces the user to indent much more stringently than they would like to indent, and which would be reasonable to indent, and for example, I always put braces {} in their own line, since at my age (of 70), I otherwise can’t “get” my code anymore, but I acknowledge I have done so all my life…

Thus, some filtering-out is needed here, too: Folding by indentation should systematically discard even the braces or brackets which include their respective blocks… since, as we all know, current screen design does not follow developers’ needs, but the (cinematographic) uses of the general public (…well: if you really consider the usual Netflix or amazon “series” “cinematography”, that is…), whilst screens just a little bit higher than usual all costs a fortune, and screens turned by 90 degrees are a joke, by their width then: In other words: We need trees of reasonable length, i.e. with just the minimum being displayed, if we want to vow our time to writing / coding, instead of spending our time with scrolling and the like.

(And, even with today’s “best” screens, we always need to have TWO windows on our screen, not just one - since screen / application management with multiple screens will become unwieldy very fast -, and so, perfectly unneeded additional indenting, just to make our writing / code even readable to very lazily indenting applications, should be out of the question: see that third party’s very unneeded suggestion mentioned above…)

Then, not all coding languages can ever be “covered”, by any editor, so:

Why not implement TWO tagging algorithms, (too, and) perfectly combineable with any any language setting, as well as just with each other AS with “fold by indentation level”:

  • SKIP lines starting* with string “xyz”, string … (array)
  • just INCLUDE lines starting* with string “xyz” (as before)

And yes, “as well as just with each other”, I said, since it’s perfectly imaginable that some user will use some language / coding language that will not be “covered”, and then they just will have to create some list of “ins” and “outs”, and together, those two lists will work perfectly indeed.

  • = And last but not least: Please - PLEASE! - also implement, in addition to “lines starting with” (for inclusion and exclusion, respectively), options for “or lines just including”, for both again, i.e. for including lines, as for the exclusion of lines, since this will not only enable the user to cope with “special cases”, i.e. with systematic exceptions, but will also enable them to include, or even, and exceptionally, include (sic!), some lines, i.e. make easily retrievable the according code blocks…

but just adding the necessary-then “tags”, i.e. code characters, within COMMENTS following those very lines, within those very lines, to be, exceptionally (i.e. currently, up to the resolution of some specific problem) or even systematically, being included, or then, excluded, from the current folding.

I’m not so much of a coder, but I know about ergonomics: Please trust me: Do the necessary coding.

Free advice isn’t always to denigrate.

EDIT: (That single dot stands in for an asterisk, followed by my asterisks’ explanation.)



Scope-based folding was added in build 4130. I don’t believe it’s been configured for xml or html, but it certainly has been for most of the programming langues we ship.



XML/HTML syntax definitions currently don’t scope opening, closing and self-closing tags individually. Thus tags can’t be targeted as fold markers via scopes.

Beyound that HTML supports self-closing tags, which look like opening tags (e.g.: <hr>) or even doesn’t require some opening tags to be followed/terminated by closing tags. As a result syntax based folding would likely fail every here and then in real-world html code.

Correct folding tags would also require to reliably find matching opening and closing tags by name. Otherwise it might happen a </p> tag terminates a <td> folding region, if some closing tags are missing.

Opening and self-closing tags are distinguished by

  1. > vs. /> end markers, which requires branching to assign distinct meta scopes
  2. hare-coded tag names in HTML (e.g.: hr, br) as those are self-closing even though terminated by > instead of />. An attemt to implement this was made in

Such significant structureal changes are very likely to break all sorts of 3rd-party packages, which rely on (aka. extend) ST’s built-in HTML syntax. Thus I’d hesitate to implement them at this point, especially as there still keep some unsolvable edge cases, which would require semantics.

The only generic solution for ST would be to implement folding API so LSP could jump in here. LemMinX and co. are quite well in semantically parse XML/HTML and reliably specify folding markers. That’s something we can’t achieve with current techniques of ST.

With API a way to specify foldable regions is meant, which can be triggered via normal fold buttons. A plugin can already fold arbritary parts of code, but there’s no GUI element to trigger it.



The following PR attempts to add scope based folding for XML. It is not as tricky as HTML and should work reasonably reliable for well-formed documents.