Arbitrary number system for counter in multi-rename-tool

[meisl]

I'd love to use the counter function in the multi-rename-tool not only with base-10 or base-26 but eg with hex (base-16), and at best be able to specify whether eg "[0-9A-F]" or rather "[0-9a-f]" should be used as digits.

---

Currently one can define a step, eg by

Code: Select all

[C+23]

and a minimum width by eg

Code: Select all

[C:6]

(to be left-padded with the "digit" for zero, if necessary),
and a start value by

Code: Select all

[C42]

or

Code: Select all

[Cxy]

... where the start value also determines which of the two currently available number systems should be used: decimal or base-26 (using "a"-"z" as "digits").

---

It would be great to have the syntax extended (in a backwards-compatible way!) s.t. an arbitrary number system base can be specified, and maybe even which characters are to be used as "digits".

For one possible use-case see "Jede n. Datei markieren" ("[how to] mark every n-th file"; think several 10k still frame images and you want to do time-lapse or stop-motion-animation).

---
p.s.: I'm not pleading for esoteric number systems like with fractional or even negative bases. Although...

[Balderstrom]

Interesting. With a customizable base-N, one could add it to TC's ini-file or MRT ini, with the handful of settings that might require.

Of course, what might be more in-line with what you need, would be the ability to just use the existing Base/10/16 with the option to apply MOD to the counter. So that the count can be reset every X iterations.

E.g. MOD(Counter[base-10], 10000) --> Counter % 10000

And in your Search/Replace field, match "0" replace "as needed".

[meisl]

Right, having a mod operator would be equivalent*.

But I'm not sure if it would be more in line. The concept of operators would be new (but certainly interesting), whereas different number systems are already there, even if somewhat implicit. Although more or less hard-coded I suspect, so I don't think it'll be "for free" entirely.

As said, operators are quite an exciting idea. But in terms of implementation effort and backwards-compatibility of the syntax - which is a must, IMHO - adding a possibility to define the base is almost certainly less demanding.
However, I'd love to be proven wrong

Also, we shouldn't forget that not only the syntax but also the GUI would need to be extended.

---
*equivalent in the sense that the "cut-off" or "restart" part of the mod operation can always be expressed with a regular expression; well and passing the modulus operand is just the same as defining a base.

[Balderstrom]

I was just thinking that MOD could be added without a complete overhaul, especially if you could recursively mod (mod of a mod...).
In the search/replace field without doing regex for instance, TC allows search: 5|6|7|8|9|10
replace: A|B|C|D|E|F

I have a few of those types saved for fixing MP3 file names.

And changes that don't require more than a minor adjustment to the existing GUI are more likely to be considered by Mr.Ghisler. (From my experience at least).

[meisl]

Agree.
Your example of nested/repeated* application of the mod operator is something that can't be achieved by regular expressions on arbitrary-base numbers.

But why do you think that introducing operators - be it only one, namely MOD - would actually be easier than just moveing from two to arbitrary number bases
In fact, I suspect the contrary is the case. Wrt to each, syntax, GUI and implementation.
What am I overlooking?

---
*"recursive" is more powerful than nested/repeated, but of course related. Introducing the concept of recursion would actually mean to introduce proper functions...
My main point is that operators, and even more so functions, require interpretation performed by TC (with scope etc), while "yet another" base wouldn't.

[Balderstrom]

Not sure, but I would imagine MOD could just be a checkbox, that opens a dialog box to insert either something like "[C] % 100"; and the post-procesing by TC would be a single line function applied to the counter, but then I've lost hope for anything I've ever suggested. And in the last few years TC has become little more than an APP-Launcher for me --- aside from passing subdir-branchview filter lists and file-lists to AutoHotkey for post-processing ... since Ghisler refuses to add internal scripting to TC; nor fix quoting of files:
You can't manually apply quotes around "%P%S" and theres too many characters that cause CMD-Batch to completely choke unless the filename is quoted. TC will auto-quote when theres spaces, but wont let you force quote everything.

TC is becoming the stagnant one among its peers. Other File managers have internal scripting with access to all internal commands -- (off the top of my head) DoubleCommander, FileBoss, Multi Commander, XYPlorer and numerous others.

Multi Commander, is probably one of the more interesting file managers that I've come across in quite a few years. Though theres a handful that I need to test again as they've been updated within the last 6-12 months (since my last File Manager shoot-out).

EDIT:
It wouldn't even need to be a checkbox, one could do this in the FileName box: [C % 100]__[N]

Of course if anyone else drops in on this thread, there will likely be a recommendation to just "write a file-rename plugin".

[meisl]

and the post-procesing by TC would be a single line function applied to the counter

Ah, now I see. Not quite true if you allow nesting I guess.
Anyways, quite the same point applies to arbitrary base: since there's base-26 there must be some code already to convert numbers (represented as bit strings) from and to that system. For example, converting to:

Code: Select all

do {
    out = digits[n % base] + out; // prepend new digit
    n /= base;
} while (n > 0);

Almost trivial, and it's just a matter of letting the user set a value for `base`in some way or another.

[...] something like "[C] % 100"
[...]
EDIT:
It wouldn't even need to be a checkbox, one could do this in the FileName box: [C % 100]__[N]

"[C] % 100" wouldn't work because it already has a (different) meaning, it needs to be something like "[C % 100]". That's what I mean by syntax: what goes into the FileName box.
Checkbox, dialog, dropdown... is what I mean by GUI. Any extension needs to be in both.
As I said, defining a modulus is no different from defining a base, so there's no difference wrt GUI: just another field where you enter a number (in decimal there).

Regarding which digits to use: you're right, that can be done with search/replace. So it'd probably be better not to put it into the counter.
Note that you cannot do base conversion with search/replace, even with regular expressions.
What you can do with it, however, is cut off leading digits, which corresponds to taking the remainder for a fixed modulus (=base).

So that means MOD (without nesting) + regex search/replace is strictly less powerful than arbitrary base + regex search/replace.

The example I gave in the OP is just one. What if I actually want my files numbered in hex, without "restart"? With MOD I can't.

[Balderstrom]

I'd probably write an AHK script - to parse a text file, utilize TC's ability to load the MRT's file-list in Notepad and use a standard base-10 counter with a unique character.

[C]__‖__[N]

Load the file list in a text editor, and Use AHK to parse that file changing the base-10 counter to whatever base you want. The code needed to convert bases would only need to be a few lines long - examples of the actual math I was reading on Wikipedia recently.

EmEditor is another fine program, which allows you to access all of its internal commands, and run scripting on text in an open file, or parse multiple files. It can use Javascript and one other scripting engine. If I was to go that route, I'd still use AHK as the glue: grab the title from the Notepad that was open, so that we can get the path where that file exists, so it can be run through EmEditor and JS, save, then AHK to automate the closing of the Notepad window to pass control back to MRT.

Again though, workarounds... I kinda get tired of workarounds

[meisl]

The code needed to convert bases would only need to be a few lines long - examples of the actual math I was reading on Wikipedia recently.

Sure. As I said in my previous post: almost trivial. Therefore it shouldn't be anywhere near requiring a "complete overhaul".

Again though, workarounds... I kinda get tired of workarounds

Look, that's why I posted it in the suggestions forum, rather than ask for a workaround

[meisl]

@ghisler: could you please give a short note on how you estimate the effort of implementing the original suggestion (custom base, no operators)?

[ghisler(Author)]

Unfortunately it's not currently planned - it wouldn't be very user friendly either to have to rename files just to select every nth file...

[meisl]

Thanks for responding ghisler, and I agree with you that it would be nice to have a more direct way of selecting every n-th file.

However, there isn't any so far; and what's more - this is just one example of a use-case. To me, having a custom-base counter for actual renaming would be valuable in itself.

So, let me kindly ask again: would it really be that difficult / a lot of effort to implement, from your perspective?

[Balderstrom]

Click the button to open the file-list in Notepad;
Copy/Paste to an Editor like EmEditor -- which allows you to write
*multiple* regex'es in what is called "Batch" Replace, which also allows you to save the list of regex'es as a sequence to use again later.

Here's one I use to parse Opera 12's Bookmark.adr file.

Code: Select all

:: ^(\t#FOLDER\n.*\n\t)NAME=
:: $1FOLDER(NAME)=

:: ^\tNAME=Speed Dial\n\tURL=opera:speeddial$
:: \tSPEEDDIAL=Speed Dial\n\tOPERA=opera:speeddial

:: ^(\tURL=(.+://|opera:)[^<]+)$
:: \t$1

:: ^(\tNAME=.*)$
:: \t$1

:: ^([^\t])
:: \t$1

:: ^\t[^\t]*\n
:: 

:: ^\n$
:: 

:: ^\n
:: 

:: \t\t
:: 

:: ^URL
:: \tURL

:: ^NAME=
:: 

As I think I mentioned before, EmEditor also allows you to script parse files as well.

Windows Scripting Host
EmEditor macros are based on the Windows Scripting Host (WSH) engine, so you can use various Windows Component Object Model (COM) objects. For example, you can perform regular expression searches using the RegExp object, manipulate files using the FileSystemObject object, create a short-cut, manipulate the Windows Registry using the WshShell object, or work with networking functions using the WshNetwork object. Additionally, you can create and execute a macro that utilizes an external application that supports Automation (such as Word and Excel) to copy a document created in EmEditor, then paste into, and print it from the external application.

Features
EmEditor Professional allows you to create functionally-rich macros using JavaScript or VBScript. Features of the macros include:

• Windows Scripting Host
• Support for JavaScript or VBScript
• Macros That Can Define Most Operations in EmEditor
• Integrated Development Environment for Macros
• Modular Design of EmEditor Macros
• Keystroke and Mouse Operation Recording and Playback

[meisl]

Balderstrom, I know how to do it on my own, outside TC (personally, I'd prefer PERL).

BUT: wouldn't it be nice to have it integrated in the MRT?
Furthermore: since there's already base-10 and base-26 it should be almost a no-brainer to implement (@ghisler: or, if not, why?).

That's why I'm suggesting a small tweak for the MRT, rather than asking for work-arounds.

[Balderstrom]

I agree with you. Unfortunately, the author of closed-source TC does not.
To get anything implemented in TC requires:
1) An overwhelming demand from a diverse group of users (even then it still relies on #2.
2) Does it tickle Ghisler's fancy, and does he think he will use it.


I prefer gAWK to Perl, but that's probably because I found Perl lends itself to obfuscation - and can be a real PITA to deal with someone-else's Perl script - or even your own months/years after the fact.