UDL: Folding with Alt-0 no longer works correctly

peklei

Since a few versions the folding of all text blocks no longer works.

Years ago, I defined a simple UDL which I have used ever since for files with notes in which sections are to be shown or hidden. These are defined by the characters [[ at the beginning of each new block:

To get by without an end identifier, [[ is defined in the UDL as the “Middle” identifier:

This allows me to show or hide each individual block, e.g. block e with text f and g:

What no longer works is Alt-0 (or the corresponding menu command). With this, a horizontal line is displayed under each [[-line (so the parser recognizes the correct folding points), but the following block is not hidden:

Is this a regression or what is the reason or how can I define the UDL differently to make it work again?

(NPP V8.8 32bit and V8.7.x 32bit and maybe earlier; Win11 and Win10 64bit)

PeterJones

@peklei said in UDL: Folding with Alt-0 no longer works correctly:

Based on your description, I do not agree with the claim in your title: It’s not really that Alt+0 no longer works; it’s that using just the “middle fold” for a UDL no longer works. With a fully-defined folding for your UDL, or with any of the built-in languages’ folding, Alt+0 works as expected.

Is this a regression or what is the reason or how can I define the UDL differently to make it work again?

I’m not sure I would classify it as a regression. I don’t think it was meant to be officially supported that you could define a “middle” without an “open” and “close” for the folding, so you were relying on unspecified behavior (and unspecified behavior, not being supported/specified, can change at any time)

how can I define the UDL differently to make it work again?

Off the top of my head, I don’t know of a way. I might play around with it as I have time, and see if I can come up with something. (I’ll also play around to see when the behavior changed, because I didn’t think there had been any UDL-folding changes recently; maybe it was the v8.7.8 folding performance change, but I wouldn’t’ve thought it would change something specific to the UDL.)

peklei

@PeterJones:
Thank you for your thoughts! You’re right about my imprecise wording.

Nevertheless, it is remarkable that the parser obviously knows exactly what to do, because it folds individual blocks exactly right, and even with Alt-0 it changes all “-” to “+” exactly right, and marks all blocks to be hidden with a line - except that it does not make the corresponding lines disappear themselves.

I have already tried different configurations in the UDL GUI, but so far without success.

PeterJones

@peklei ,

I have confirmed with v8.7.8 - v8.8.1:

My example text:

{
	open->middle
[[
	middle->end
}

a
[[b
c
d
[[e
f
g
[[h
i
j

And to ensure that it’s not just because open/close aren’t defined, and to compare the behavior, I also defined { as open and } as close, around the [[ as middle:

Expected (and what you get if you manually close the [-] :

vs Alt+0:

It was definitely the v8.7.8 change to the performance that caused it, because v8.7.7 works as you expected – whether or not you have open/close defined, the middle was working, and would fully collapse the same amount whether manually clicking or using the Alt+0 to collapse all (so both looked like the “expected” screenshot).

I still think that you were relying on undocumented/un-guaranteed behavior – because the intention is for Middle to only come in between (“in the middle of”) an Open and a Close. And as you can see from even my Alt+0 screenshot, when you correctly have an Open/Close pair around any Middles, the Middles fold properly with Alt+0 as well.

So, you didn’t say what the purpose of your UDL was, and whether you get to define the syntax of the file for your own use, or whether you have to follow someone else’s definition for exactly how the file must look. But if you do get to choose, then I recommend something like

]]StartOfFile]]
a
[[b
c
d
[[e
f
g
[[h
i
j
]]EndOfFile]]

=> Alt+0 =>

By correctly having the Open and Close sequences at least once in your file, you can have as many Middle sequences between them as you want. So if you are allowed to put something like ]]StartOfFile]] at the start and ]]EndOfFile]] at the end (you could have it simplified to be ]] or whatever other unique symbol you want – I mean, my initial example showed { as open and } as close, and that works, too)

If you don’t get to define the file syntax, but it has a comment syntax and can have a comment on the first and last line of the file, we might be able to come up with a way to include that comment as part of the Open and Close for the folding: For example, if # is the start of a comment for your language, then you could use #START]] and #END]] as the Open/Close and put those lines as the first and last in the file)

Also, since the end of file is a de-facto end-of-fold, you can skip defining the Close if it’s always just going to be the last line of the file. So you could make the Open look more like Middle by having Open = [[[ or something similar (like #[[ if you need it to be a comment), then (if possible) make the first line of your code [[[ (or #[[ or whatever).

To sum up: I don’t think you’re ever going to make it work reliably the way you previously had it, with just the Middle, because the Middle must come between an Open and a Close to be defined on how it should behave; but if you can define and use an Open and Close in your file, then you would be back within defined behavior, and you could reasonably expect it to behave the same across versions, and to have both manual folding and Alt+0 do the same thing.