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.

[peklei]

@PeterJones,

Thank you again for your tetsts and suggestions!

As I wrote in the first post, the purpose of the UDL is to help me structure my own files with notes. This means that I am not required to adhere to a predefined syntax. However, I have been using the UDL for many years, so if I change it, I would have to rewrite all previous files. For new files, I have come up with a solution similar to the one you suggested: I could define a start identifier and place it somewhere before the first section of the file. But this solution doesn’t work for existing files. Therefore, it would be better if I could adapt the UDL so that it works for existing files too.

Do you think it’s worth asking the author (Don Ho) if the change in V.8.7.8 must inevitably result in this change in behavior, or if it’s just an “oversight” that can be corrected? Of course, due to the reliance on “undocumented/un-guaranteed behavior,” I can’t be sure about future changes, but that’s a matter for the future …

[PeterJones]

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

Do you think it’s worth asking the author (Don Ho) if the change in V.8.7.8 must inevitably result in this change in behavior, or if it’s just an “oversight” that can be corrected

Do I think it’s worth it?

• I don’t think it’s worth it for him, because it’s a strange edge case relying on undefined behavior, and there are lots of other features/bugs in the application (and even in the UDL system) that I’d much rather see fixed (IMO)
• I don’t think it’s worth it for you, because UDL feature requests and bug reports tend to go completely ignored for years – that I can remember, there’s only been a few critical bugfixes in UDL (and, to my memory, no feature improvements) since I started paying attention to N++ development about a decade ago

If you could show that the v8.7.8 change also revealed a similar bug in one of the built-in lexers (showing that it worked in v8.7.7 and changed/broke in v8.7.8), then it would definitely be worth it. (But, for example, Visual Basic, which uses else followed by indented blocks as a middle-fold, works “just fine” with Alt+0, even if you don’t have the if-then and endif open/close pair surrounding it. So I don’t think it’s a general bug.)

But it’s up to you whether it’s worth your time to ask; we have a FAQ explaining where feature requests go.

[PeterJones]

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

if I change it, I would have to rewrite all previous files

Since your UDL has the .wtx extension, Replace > Find in Files with *.wtx in the filter and FIND=\A (for start-of-file), REPLACE = [[[\r\n (or whatever your new start sequence is, followed by \r\n to add a newline, if you want), SEARCH MODE = Regular Expression – that could update all the .wtx files in a given directory or directory hierarchy.

Not overly onerous, IMO; but completely up to you whether that’s easier and more productive for you than asking for a feature which may or may not ever be implemented.

[peklei]

@PeterJones,

I suppose you’re right. I’ll leave it at that and adapt the old files accordingly.

It is really remarkable that the mentioned else-construction works in Visual Basic. It would be interesting to know how this is implemented there and whether it can be recreated in a UDL definition.

Thanks for the tips on changing the files, and for your time and effort on this topic!

[PeterJones]

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

It would be interesting to know how this is implemented there and whether it can be recreated in a UDL definition.

In a UDL definition? No. Each built-in lexer has dedicated code for deciding where to fold (if that lexer has folding). The source code for UDL has a separate set of code, that is purely keyword-based.
From the “UDL definition” point of view, all you can do is set the open/middle/close keywords; you cannot change the logic from the UDL interface or config file. If you wanted to change the logic, it would require a change to the UDL source code, which requires a feature request