Incorect Fold Generation

This fragment will generate 2 folds

sMapDataTracking .struct topCharsToNext .byte ? topIndex .byte ? bottomCharsToNext .byte ? bottomIndex .byte ? .ends

it will create a fold on the first line and another on the bottomIndex .byte ? line which will extend beyond the .ends - the fold should be first line to last

3.3.4 20150517, Windows 10, Tass 64 mode, Java version 8 Update 45 (build 1.8.0_45_b14)

I'm not sure if it's a good idea to use structural and label folding together. I always considered them as either/or. If you switch off label folding this will work as expected, but I not sure how structured is the rest of your code. If it's "structured" by labels/local labels only without using .proc/.pend directives, then this might not be optimal.

yeah neither case works. using structs, blocks is not a 100% thing, I would think code that is split by labels and references a data struct, or enum grouping or macros in a function would be a common way to code. adding .proc/.pend to each function sounds problematic as it will generate a local scope to each function, meaning if you want to call the function you will need to call it with label.functionLabel and then if it wants to access global variables... And if that function has sub functions, you would then nest them so the parent can see it, but then the other function is out of scope to reference anything the parent has...

also dstructs shouldn't generate a collapse as they are an instance of a struct not a definition

The fold generation was improved in 20150917, so that non-nesting folds can't escape nesting folds, and that label folding starts on top and not on bottom for "grouped" labels.

In practice for your example it means that you'll still have an additional fold inside struct, because of the enabled label folding, but unlike before now it starts on the first label and stops just before the struct ends.

Getting rid of the nested fold is possibly unwanted in some situations and checking if this is the only one and it's really covering everything is rather expensive operation compared to the current maximum depth of 2.

As for dstructs, they are not much different from any other data directives, and it's not clear if we want there a fold or not, after all there's a normal label, and then normally it should fold. And if it's surrounded by other data stuff with labels then probably it's not good that it splits this group.

And there are the assignments which now don't fold. But even for them there could be arguments that this should fold too as it'd be nice when there's a lot of them.

Overall this folding on label thing is a big grey area, without concrete rules, therefore no good solutions. Except maybe when it folds every time at the start of a group, no matter what.

As for nested sub-functions, they can reference anything below them which include all parents and their labels/variables, I'm not sure I could understand what exactly is out of scope.

If only asm had { } :)

I'm still seeing a label fold on the last line of the struct, not the first.

I think a few extra rules might be able to get it 80%. Upon a .struct ignore everything except .struct and .ends so once you are in a struct only structs form more folds. .dstructs are single line and should not generate folds, unless like assigns there is a row of then and you want to new line delimit the group .unions should ignore all but .structs until the end of the union so it forms a fold for it self and child structs .macro and .function should ignore all children until the end, they should be short and sweet anyway .if,.elsif.else et al should allow all children types to make groups .switch should make a fold for .switch and per .case,.default which will allow all children to make folds until terminated by a .case or .endswitch .for,.rept should fold to a .next and ignore all in-between .break,.continue. lbw, goto, include binary warn, error option should not form folds .proc,.sections, .page should allow all children to form folds .block and .weak, should only allow .structs, .unions to form child folds

Making 4 types

1. ) only allows it to make a fold until it ends .struct, .for ... 2.) allows it, .struct and .union to make sub folds 3.) does what you have now 4.) never makes a fold

not sure how your parser works, might be easy to implement or totally of the planet hard ;)

Assembler and curly brackets don't mix. Unless it's for dictionaries.

Probably wrong version then (was the one I mentioned released yet?), as it looks like this here:

> aa .struct
> a1 .byte ?
  a2 .byte ?
L a3 .byte ?
L    .ends

The parser has no idea about context as it has to work on the fly when you type. So it can't tell which "type" of fold is it inside currently without re-parsing potentially large amount of text every time you type in something. For nesting/non nesting I did some bit hacks, but it does not scale to further types.