Feature request;

[JackFoo]

Hi, this are some of the feature I've collected in my wishlist for TC:

1. Regular Expressions (Search, Multi-Rename) (Not likely but one can hope).
2. Search in background (Oh Yeahh).
3. Unpack/Pack in background (also with external/internal packers maybe make TC's "packing" box disappear if the packer has an interface).
4. Always delete in background (like copy command).
5. Make %N work properly it currently puts [relative path\name].
6. Add %R for relative path.
7. Separate name and extension to %N and %E.
8. IMO %T and %M should not pass any value if no file is selected in target pane.

[pdavit]

And to add up to your list my biggest wish so far:

9. Support of macros for TC’s internal commands with scripting capabilities!

And secondarily:

10. More “sophisticated” file selection bookmarking and retrieve of bookmarking.

[Hacker]

JackFoo,
Assuming you know the current situation / standard answers concerning #1 - #4.


maybe make TC's "packing" box disappear if the packer has an interface

Just in case you do not know, you can press Esc to make it disappear.

HTH
Roman

[JackFoo]

JackFoo,
Assuming you know the current situation / standard answers concerning #1 - #4.

What does "standard answers" mean? No, yes, maybe?

Just in case you do not know, you can press Esc to make it disappear.

If you press ESC in the middle of packing (say with RAR) the packing is canceled. So this isn't what I asked...

Cheers.

[Hacker]

Standard answers are:
#1. Christian says Regexps are too complex for the average user so we probably won't implement them anytime soon.
#2. See please http://www.bearfacts2.com/forum/showthread.php?s=&threadid=327 .
#3. Can't be done safely because a) the packers (or the DLLs TC uses) aren't threadsafe (similar to #2) (at elast I think this is one of the reasons) and b) unexperienced users might delete the files being packed because they'd think the packing is completed.
#4. Would probably be to dangerous - in case you just realize you shouldn't have deleted that it might take a long time to abort (switch to the window in background).


If you press ESC in the middle of packing (say with RAR) the packing is canceled. So this isn't what I asked...

I meant pressing Esc in TC when the Packing in background box is shown - Esc closes the box and you can continue working in TC.

HTH
Roman

[Pradera]

Standard answers are:

#3. Can't be done safely because a) the packers (or the DLLs TC uses) aren't threadsafe (similar to #2) (at elast I think this is one of the reasons) and b) unexperienced users might delete the files being packed because they'd think the packing is completed.

How's that different from copying in the background, or packing files with internal zip in the background? We have the packer window on all the time anyway, just like the 'packing in the background' window...
The threadsafety is much stronger argument.

#4. Would probably be to dangerous - in case you just realize you shouldn't have deleted that it might take a long time to abort (switch to the window in background).

Setting attributes like 'always delete in the background' is already stuff for more experienced users, so I wouldn't worry here. Speaking for myself, I _always_ delete files in the background, and never watch what I do (that's what Norton Unerase is for ;). There's plenty of time to think about what you're doing when the confirmation dialog appears.
It's not like you're forced to delete in the background... that's what user-settable attributes are for...

If you press ESC in the middle of packing (say with RAR) the packing is canceled. So this isn't what I asked...

I meant pressing Esc in TC when the Packing in background box is shown - Esc closes the box and you can continue working in TC.

Well, if you can do that, then why not simply put a 'Pack in Background' button or attribute there? Same thing, only easier.

[JackFoo]

#1. Christian says Regexps are too complex for the average user so we probably won't implement them anytime soon.

Ok, probably; (this answer I already heard)

#3. Can't be done safely because a) the packers (or the DLLs TC uses) aren't threadsafe (similar to #2) (at elast I think this is one of the reasons) and b) unexperienced users might delete the files being packed because they'd think the packing is completed.

A completely mute point! What happens if I'm using windows explorer rightclick a folder and select add to rar in background-> it runs happily in background and I can unsafely delete the folder so where is the difference? Why should TC be different?

#4. Would probably be to dangerous - in case you just realize you shouldn't have deleted that it might take a long time to abort (switch to the window in background).

Now this is just too funny, what if the file is 30mb? For small files/big files deleting take up to a second, only if you try deleting a directory structure it would take more so why directory structures are more important (not mentioning that till you remember you weren't supposed to delete it half would already be gone). Use recycle bin if you aren't sure, another point is that you can press [background] in delete dialog...

About thread safety of packers: I think rar is thread safe, it has a background option for archiving, so given TC has a rar specific options why wouldn't you just specify ( [x] this packer is thread safe ) and TC would act accordingly.

P.S. I think a sticky post on this forum with the complete FAQ would probably be more productive; Then it would be simpler to "throw" newbies there :-) "Did you read the bl**dy FAQ!!!!!!!"

P.P.S. Did you know FTP passwords are cut at around 121 chars... (no warning given)

Cheers.

[Hacker]

OK, well, my answers were (to the best of my knowledge):
#1: Christian's official stance
#3: a) probably wrong, was thinking about the DLLs for unpacking, not packing and b) Christian's official stance
#4: My best guess as to why it isn't implemented

so I guess I cannot comment much on your comments, since you now know about as much as I do concerning these topics.

HTH
Roman