Feature: Start menu params should support selected files

[katatonic]

Currently the parameters for a Start menu command support %n, %m, %p, %t, and paramters to create a list of the names of the selected files and pass the list filename as a parameter.

With these parameters it is impossible, for example, to run an external diff program, passing as parameters the same files as those that the internal diff would use (normally would run on the 2 selected files).

So it would be nice to also have parameters for the full file names (path+name+ext) of the individual files in the selection, for exapmple %1 for the first file in the selection, %2 for the second, etc.
It should be possible to use the selected files in the active window (%1a, %2a, ...), or in the target window (%1t, %2t, ...), and some notation should mean that TC should be "smart" and choose the appropriate files (for example if we have specified %1 %2 in the command but there's only 1 selected file in the active pane and 1 in the target, it would use them)

This would make it possible to have an external diff, or whatever else program that expects more than one filename as a parameter.

Mentioning external diff - actually, TC should also provide an ordinary option for an external diff program, just like the options for viewer, editor and packers.

[SmellyCat]

I am looking for this ability to specify parameters using selected files.
Has it been implemented in the meantime?
Are there any plans to implement it?
What's the best way to make a feature request?

[Hacker]

Has it been implemented in the meantime?

Nope. Still have to workaround with lst2str, lst2multi (see ghisler.com - Addons) or lst2run (search this forum).

Are there any plans to implement it?

I don't think we know that.

What's the best way to make a feature request?

Search this forum to see if a similar request has been made. If yes, then post in that thread, if no, then either open a new thread or write an email to support at ghisler dot com.

Thread +:
More users see it -> more users can show support
Users can offer workarounds
The author will read it but might not respond
Takes off workload from the author

Mail +:
You have pretty much a more guaranteed answer from the author.

HTH
Roman

[SmellyCat]

Thanks for your reply.
lst2str seems to be exactly what I wanted.
However I think version 1.19.1 seems buggy.
Besides adding the files in the list to the command line, it also adds some garbage text as an extra parameter.
Is this a known problem? Can I download a working version from somewhere else?

[Lefteous]

2SmellyCat

However I think version 1.19.1 seems buggy.
Besides adding the files in the list to the command line, it also adds some garbage text as an extra parameter.
Is this a known problem?

Same for me.

[SmellyCat]

I was able to get version 1.16 from this board.
It works fine now.
Someone should remove 1.19.1 from the Ghisler site and replace it with an older working version.

[ghisler(Author)]

I will try to contact the author of the plugin about the problems.

[JackFoo]

Hi, I'm sorry I didn't see this post before (thanks Christian for contacting me). Anyhow, I'm trying to see what the problem is, for now I can't seem to reproduce it... any help would be most appreciated in the form of your OS and your command for the program and if and when it happens.

Thanks.

[JackFoo]

Bump...

[ghisler(Author)]

2Lefteous
Can you give JackFoo an example of when the problem occurs? I haven't seen this problem myself yet.

[Lefteous]

2ghisler(Author)

Can you give JackFoo an example of when the problem occurs? I haven't seen this problem myself yet.

He has already contacted via email.

[icfu]

The problem I have for example with BareGrep:
http://www.baremetalsoft.com/baregrep/usage.php

The only way to make lst2str pass everything correctly is like that:

Code: Select all

command: X:\path\to\lst2str.exe
parameter: /S:"X:\path\to\baregrep.exe searchexpression" /X:"X:\path\to\baregrep.exe" /L:"%L"

The problem is that without the dummy above (the additional baregrep.exe in /S) the executable is missing in command line, baregrep.exe therefore ignores the "real" search expression and takes instead the first passed file as search expression.
This bug leads to additional problems in BareGrep, I have seen for example corrupted file paths I haven't entered myself, one time even a part of my computer name being inserted as file path but these are just bad side effects due to incorrect error handling in BareGrep I suppose...
Anyway, those errors would not occur if lst2str.exe would not eat the exepath...

See this posting, too:
http://www.ghisler.ch/board/viewtopic.php?t=1667

My OS is (german) XP SP2. If I can help with additional information, contact me, JackFoo. Unfortunately you have not entered any contact information here so I hope you will read it.

Icfu

[JackFoo]

I've sent you an email, if you reply to it (or post your email address) I'll be able to send you a fixed version so you could see if it solves the problem.

Cheers.