I've noticed while batch renaming files based on their existing filenames that the format modal dialog's interface does not render leading whitespace in the preview line.
where the first cutLeft function (56 characters) should show a leading whitespace character for the first example, it shows the same preview as the second cutLeft example (57 characters).
The first $mid (50 chars) is a demonstration of the characters preceding the target number string.
The second $mid (55 chars) should preview with leading whitespace; the third (56 chars) should truncate the whitespace, as the preview correctly shows, and likewise the fourth (57) should also include the whitespace.
Trailing whitespace in all examples is included where appropriate.
I was wondering if this might be due to Windows' default behaviour with leading whitespace, or is Mp3Tag intentionally trimming leading whitespace to avoid file write problems on execution? If the latter, I think a warning should be shown when OK is pressed, or a warning shown all the time if a leading whitespace character is detected.
The preview window is a little unclear when strings have leading or trailing whitespace. It might be useful if the preview field could more clearly indicate its boundaries, so you can obviously see if you have leading or trailing whitespace.
MP3tag generates valid filenames. And as WIndows does not allow leading space characters, it is not attempted to create such a filename.
Works as designed, I would say.
Perhaps the preview should more clearly indicate when there is a leading or trailing space being discarded? I can foresee when this might either cause confusion with further processing if someone mis-counts, particularly if whitespace is still included in the output string before being discarded for the filename/path. It might also cause tagging quality problems if the whitespace is still carried through in filename -> tag processing.
I do not see a reason why the space characters should be treated in a different way than other characters that would lead to an invalid filename or folder name. If you have e.g. the colon in a filename then this would also be silently be replaced by something valid or nothing at all.
Also, it is rather difficult to show a final result which leaves out certain characters.
I suppose the point I'm trying to make is that it could be helpful for users to be notified if an 'illegal' character, as far as the OS is concerned, would have been included in an illegal position in the file name or path, as a result of a function transform.
For characters like forward slash, colon etc, they are silently replaced with a whitespace character if you attempt to include them in a filename for example. In many cases that's acceptable as it is midway through the filename. It is Mp3Tag's working around Windows inconsistency that causes some confusion, exacerbated by the way the previews are shown in the modal dialog.
It's not a dealbreaker, more of a UX suggestion concerning UI and scripting consistency.
In the rename tag->file or where a tag->tag targets _DIRECTORY or _FILENAME, perhaps a small exclamation mark symbol could be shown to warn if an illegal character was potentially going to be included? With a (possibly clickable?) tooltip to explain the reason for the warning, that could link to an Mp3Tag doc page?
It could also help people improve their function design and regex writing by nudging them towards dropping whitespace or pattern matching and replacing with a more suitable character.
No.They are dropped without additional whitespace. If you want them be replaced by something else you have to use $validate() or $replace() scripting functions.
