[TC 11.57] New file/new folder dialog: Handling of prefix for a counter placeholder [C]

[white]

This issue is earlier mentioned here.

• Press Shift+F4 or F7
• Enter:

  Code: Select all

  <1-2>[" (PREFIX) " L YMD Ca" (POSTFIX)" n] Test
  

Result:
20260508 Test
20260508 (prefix) b (postfix) Test

I don't expect the prefix to be in lowercase, because L comes after the prefix.
I don't expect the prefix to come after the date. I expect the prefix to be ignored because it is not next to the C placeholder.

So expected:
20260508 Test
20260508b (postfix) Test

[ghisler(Author)]

The conditional prefix belongs to the counter C. It is only applied when encountering the counter field C, so everything which comes before the C will be handled first.

[white]

The conditional prefix belongs to the counter C. It is only applied when encountering the counter field C, so everything which comes before the C will be handled first.

Which users obviously will understand because?

[ghisler(Author)]

Because the other fields don't use conditional prefixes! This is a very constructed example just to get in more bug reports. Sorry but I will not change this. The only solution would be to "forget" the prefix of show <Error> when the prefix is followed by a different field. How would that help the user?

Moderator message from: ghisler(Author) » 2026-05-11, 07:59 UTC

Moved to will not be changed

[white]

Sorry but I will not change this. The only solution would be to "forget" the prefix of show <Error> when the prefix is followed by a different field. How would that help the user?

That would help the user because that behavior would be more predictable and less unexpected. As you said, other placeholders don't use conditional prefixes.

This is a very constructed example just to get in more bug reports.

The accusation that my motivation for making bug reports is "just to get in more bug reports" is untrue. Making a wild accusation like that is crossing the line of acceptable behavior. It's also very ungrateful for the time and effort spent creating clear bug reports, which is not an easy task. I want an apology for that.

[ghisler(Author)]

I'm sorry, this remark was indeed unfair. I will change it so you will get <Error!> when the closing quote isn't immediately followed by "C", just like when the opening quote of the suffix isn't immediately following the C.

[white]

11.05.26 Fixed: New file/folder dialog: Show <Error!> when double quotes in a field are separate from the C field, e.g. <1-5>["prefix" C "suffix"]test (32/64)

Tested with TC 11.57a pre1 32-bit and 64bit. <Error!> is shown OK.

It's an interesting implementation that a postfix for one counter can be a prefix for another counter at the same time. For example:

Code: Select all

<1-2>==[C"_"C5]--

Result:
==--
==2_6--

I would expect this result only with:

Code: Select all

<1-2>==[C"_"""C5]--
<1-2>==[C"""_"C5]--

Code: Select all

<1-2>==[  C"_"  ""C5  ]--
<1-2>==[  C""  "_"C5  ]--

In the first example in this post, I expect "_" to be the postfix for the first counter and that the second counter doesn't have a prefix. So I would expect it to behave like:

Code: Select all

<1-2>==[C"_" C5]--

Result:
==5--
==2_6--

[ghisler(Author)]

It's an interesting implementation that a postfix for one counter can be a prefix for another counter at the same time.

This is just invalid input which isn't caught. All examples which don't have a space or ] after the closing double quote should return an error, including these two:

<1-2>==[C"_"""C5]--
<1-2>==[C"""_"C5]--

I will add code to detect this and show <Error!>.

[white]

This is just invalid input which isn't caught. All examples which don't have a space or ] after the closing double quote should return an error, including these two:

I see. Isn't that inconsistent with the other placeholders? Instead of an error shouldn't it accept a new placeholder after the last quote of a postfix for placeholder C?

Example:

<1-2>[YMD"("C")"]

Placeholder M is allowed directly after Y.
Placeholder D is allowed directly after M.
Placeholder C is allowed directly after D.

<1-2>["("C")"YMD]

Placeholder Y is not allowed directly after "("C")". Isn't that inconsistent with your overall implementation?

[ghisler(Author)]

Hmm, I will check whether I can support that. The problem is that the C placeholder is special. For example
<1-5>[CN]
doesn't mean a counter followed by the original name. It means an alphabetic counter starting with character N.
That's why it's so difficult to handle multiple parameters within the same brackets when a counter field is involved. Therefore a space is currently required to separate the counter field from other fields.
I can handle it with quotes because it's not ambiguous, but in general a space is needed, because there are just too many cases to handle. For example
<1-5>[C1:5N]
could be split into [C1:5] and [N] when analyzing the parameters very closely, but sometimes it's not that obvious. Therefore I currently require a space or closing bracket after the C placeholder.

[white]

The problem is that the C placeholder is special. For example
<1-5>[CN]
doesn't mean a counter followed by the original name. It means an alphabetic counter starting with character N.
That's why it's so difficult to handle multiple parameters within the same brackets when a counter field is involved. Therefore a space is currently required to separate the counter field from other fields.

I was aware of the complexity. The complexity is mostly the same as in the multi-rename tool, and the complexity also exists for other placeholders. See for example these examples:

Code: Select all

[N 4-10]                : Characters 4 to 10 from name, with padding
[N  4-10]               : Equivalent of [N][4-10]

---

I can handle it with quotes because it's not ambiguous, but in general a space is needed, because there are just too many cases to handle. For example
<1-5>[C1:5N]
could be split into [C1:5] and [N] when analyzing the parameters very closely, but sometimes it's not that obvious. Therefore I currently require a space or closing bracket after the C placeholder.

15.05.26 Fixed: New file/folder dialog: Multiple counter fields within one pair of brackets not working correctly, e.g. <1-2>==[C"_"C5]-- (32/64)

Tested using TC 11.57a pre2 32-bit and 64-bit. Works according to implementation.

[ghisler(Author)]

Please re-check with Total Commander 11.57a RC1!

[white]

I can handle it with quotes because it's not ambiguous, but in general a space is needed, because there are just too many cases to handle. For example
<1-5>[C1:5N]
could be split into [C1:5] and [N] when analyzing the parameters very closely, but sometimes it's not that obvious. Therefore I currently require a space or closing bracket after the C placeholder.

15.05.26 Fixed: New file/folder dialog: Multiple counter fields within one pair of brackets not working correctly, e.g. <1-2>==[C"_"C5]-- (32/64)

Tested using TC 11.57a pre2 32-bit and 64-bit. Works according to implementation.

Tested OK using TC 11.57a rc1 32-bit and 64-bit. Works according to implementation.

Moderator message from: white » 2026-05-20, 14:10 UTC

Moved topic
» from TC11.x bug reports (English) to TC Fixed bugs