Rename List Mode Quirks

[jupe]

I noticed a few things about rename list mode that may be unintended, thought maybe you might want to look into them.

1) It seems really slow compared to the other batch rename operations, is it able to be easily optimized at all? While testing I noticed that the speed differential occurs only when input filenames are supplied, note the speed difference between these 2 commands that do essentially the same thing:

Code: Select all

	sel 1, 7; rename "l", "1|2|3|4|5|6|7", "p",, 64;
	sel 1, 7; rename "l", "a|b|c|d|e|f|g", "p", <selitems |>, 64;
	echo "done";

2) After a rename is performed the files are de-selected (only when you provide the input items names using the 3rd parameter), this doesn't happen in other batch rename modes so is it possible to retain selection after a rename is performed? I know I can add scripting lines to re-select afterwards (unless edit pattern used in dialog) but it would be nice not having too.

3) It doesn't get added to the undo log (again this seems to only be when input filenames are provided), could it be added?

It really is a great feature but I always end up using renameitem or alternatives because of these issues.

[admin]

I could fix 2) and 3) but I'm having trouble seeing any slowness. The first time I tried it it was slow indeed, but never again. Is there a trick?

[jupe]

Yes I noticed that the extreme slowness was only the first time it was run too (I forgot to mention that), that is why I thought it could be fixable because usually you don't run the same script over and over, so in practice every time you encounter it on a non-testbed basis it is perceived as being very slow to the user (with no feedback to know it is working) even on this relatively small 7 files file set, granted if you run the same script repetitively it gets faster, but in general use I doubt you would do that. There is still a noticeable speed difference between the 2, even if the amount gets lessened on subsequent runs, it also doesn't seem to match the other batch rename operations speed, or even multiple individual calls to renameitem.

Anyway it just seemed to me that there could be an issue there, if you say there isn't then no worries, I just thought I would bring it up with the other items.

[admin]

No slowness here. Is a Windows reboot necessary to make it slow again?

[jupe]

Maybe to get back to extreme slow on 1st run, I haven't restarted for a couple weeks, but just a simple restart of XY makes the first line of that script return instantly, the 2nd line takes about 5 seconds plus for me.

So if you restart XY and then run this script: (CAREFUL THE FILES YOU RUN IT ON) no preview anymore

Code: Select all

	$time = <date YYYY-MM-DD hh:mm:ss.ffffff>; 
	sel 1, 7; rename "l", "1|2|3|4|5|6|7",,, 64;
	echo datediff($time,<date YYYY-MM-DD hh:mm:ss.ffffff>,"ms");
	$time = <date YYYY-MM-DD hh:mm:ss.ffffff>; 
	sel 1, 7; rename "l", "a|b|c|d|e|f|g",, <selitems |>, 64;
	echo datediff($time,<date YYYY-MM-DD hh:mm:ss.ffffff>,"ms");

I see, 45 the first time, 4897 the second, if I change locations and come back and run it again, it is like 42 and 2937, then if you run the same script multiple times they are eventually both quick, but if I change locations/perform other tasks then come back and run it again I am back to those same speeds as first time, taking 5 seconds.

Anyway like I said no worries, maybe it is normal, I just didn't think there would be such a variation between the 2 similar commands so thought it was worth mentioning.

[admin]

I see, 62 the first time, 63 the second. Not your class of problem.

[jupe]

Wow, bizarre, just so you don't think I am imagining it I made a recording in a fresh instance, anyway I guess it must be specific to me and not widespread.

[admin]

Here is mine (also tried in fresh version and after Windows reboot: no difference).

Nothing suspicious in the code as well. Both lines use almost the same code.

[admin]

In the next beta I changed something that makes it even faster here (47, 47). Maybe it helps.

[jupe]

Success !!

All good now, I see 25 to 48ms now for both lines consistently, from the release notes it looks like the prob was in sel?, ironically I was only using that in this test script because of the de-selection issue you have also now fixed.

[admin]

Wow, that's what I call intuitive bug fixing. There was an XY code line at the end of "sel" that yielded control to the OS (to do whatever it thinks is necessary). For unknown reasons your OS really used this chance and went to work for somebody else. Now that line of code was not commented as I usually do extensively, and I could not think up any reason for it to be there. It just did not make sense. So I removed it. Fingers crossed... At least it fixed your bug.

[jupe]

I just wanted to bring up something regarding rename list mode, if a empty separator is passed in the itemlist, XY takes it as <curpath> and adds an extra item, this is especially an issue when it is a trailing separator, do you think that is avoidable?
I realize it is easy to script around, but when doing list building it usually always requires removing manually in every script, which I have been doing up till now, but it would be nice if possible that XY could just ignore a trailing separator.

eg: rename l, <xy>, p, "<xy>|"; or rename l, <xy>, p, "<xy><crlf>";

If in the preview window, "Edit Pattern..." is pressed XY has removed the separator anyway, but the itemlist still can't be corrected from there.

[admin]

Sure. Fixed in next beta. Fixing it was infinitely easier than explaining the problem, so I'll skip it in the change log.