report() : support fields recursion

[jacky]

Yeah, so something like the field "Dir" is pretty cool, but what would be even better is if we could include other fields in the strings used.

For example, we could then do something like this:

Code: Select all

{Name} - {Dir -|{Size B} ({Size FLEX})|} - {Modified}

So that files could have their size shown as "2 736 204 (2,61 MB)" and folders only "-" or even nothing at all, and not " ()" which isn't really "pretty".

[admin]

I knew this was coming and I would have done it immediately if I'd seen an easy way. But the parsing is difficult since I don't want to restrict what's inside {...} in any other way (other than that you cannot use "}" inside a field). So there are unsolvable ambiguities.

A possible way would be to have a special field for DIRs like {sizedir [format]}...

[jacky]

I knew this was coming and I would have done it immediately if I'd seen an easy way. But the parsing is difficult since I don't want to restrict what's inside {...} in any other way (other than that you cannot use "}" inside a field). So there are unsolvable ambiguities.

Okay, so I thought about this, and right now I'm thinking this : what's the problem? If you agree to not only forbid the use of "}" but also its brother "{" then all you have to do (not saying it's easy, just...) is to deal with nested brackets, no?

I don't think this should be a problem, nested brackets aren't really impossible to do, after all it's already there in XY, Scripting allows/supports the use of (nested) parenthesis without problem! And since, as you mentioned, the closing bracket was already out, removing the use of the opening one should be that much of a problem IMO (Otherwise, you'll have to think about adding support of the escaping backslash...)

Again, I don't know if that's an easy way on your end of things, but from where I'm standing this looks just like what's already supported in scripting.

[admin]

I knew this was coming and I would have done it immediately if I'd seen an easy way. But the parsing is difficult since I don't want to restrict what's inside {...} in any other way (other than that you cannot use "}" inside a field). So there are unsolvable ambiguities.

Okay, so I thought about this, and right now I'm thinking this : what's the problem? If you agree to not only forbid the use of "}" but also its brother "{" then all you have to do (not saying it's easy, just...) is to deal with nested brackets, no?

I don't think this should be a problem, nested brackets aren't really impossible to do, after all it's already there in XY, Scripting allows/supports the use of (nested) parenthesis without problem! And since, as you mentioned, the closing bracket was already out, removing the use of the opening one should be that much of a problem IMO (Otherwise, you'll have to think about adding support of the escaping backslash...)

Again, I don't know if that's an easy way on your end of things, but from where I'm standing this looks just like what's already supported in scripting.

Damn, I thought you'd buy my lame excuse! I just did not feel like dealing with nested brackets in that moment... it's raining here since days you know....