%Q doesn't work with %A

[Fla$her]

1. Create a command in usercmd.ini:

   Code: Select all

   [em_test]
   cmd=cd
   param=?%Q%A %A1 %N

2. Create a button:

   Code: Select all

   TOTALCMD#BAR#DATA
   em_test
   %N
   wcmicon2.dll,21

3. Place the cursor on a name with spaces, for example "1 2", and press the button.

In the field you will see the result: "1 2" "1 2" 1 2 (instead of 1 2 1 2 1 2).

[petermad]

Confirmed

[ghisler(Author)]

Not confirmed - %A doesn't add any quotes, %N on the button does! Try this button:

Code: Select all

TOTALCMD#BAR#DATA
em_test
%Q%N
wcmicon2.dll,21

[Fla$her]

Not confirmed - %A doesn't add any quotes

Did you reproduce all 3 points exactly?

%N on the button does!

So what? %Q comes before %A, not before %N. Replace it with "1 2", the meaning will not change.
Do you see that the 3rd parameter %N is returned without quotes?

Try this button:

Why should I check %Q%N if it does not meet the required conditions, when the parameter needs to be passed in full, not in parts?

Button parameters: "value 1" "value 2"
Usercmd parameters: "-a '%Q%A1' -b '%A2'"

Expected: "-a 'value 1' -b 'value 2'"
Result: "-a '"value 1"' -b '"value 2"'"

[ghisler(Author)]

The problem isn't the %N in your param definition of [em_test]. It's %N of your button:

The button sees %N and sends the quoted name to em_test. Then em_test sees the quoted command and doesn't add any quotes to it, they are already there from the button command.

[Fla$her]

Then em_test sees the quoted command and doesn't add any quotes to it, they are already there from the button command.

This sounds like some kind of nonsense. %Q is the first parameter. Obviously, any subsequent parameters shouldn't be quoted, regardless of whether they are taken from a button or from somewhere else. I gave you an example without %N. Run from the command line em_test "bla bla" and you will get "bla bla" "bla bla" ..., which is incorrect.

[white]

%Q is the first parameter. Obviously, any subsequent parameters shouldn't be quoted, regardless of whether they are taken from a button or from somewhere else.

My thoughts:

%Q disables adding quotes to filenames and paths during placeholder substitution. The value produced by %A is not necessarily a filename or path, and no quotes are added during substitution of the %A placeholder. So it works as expected.

%Q is not an option to remove quotes from a value. Could it be added? Yes. Should it be added? It would break compatibility, which may cause problems for people. Also, quotes may be part of the filename on certain file systems. Suppose on a server you have the filename "test", which has the quotes included in the filename. When working on the server using the Secure FTP plugin, %N produces the filename "test", including the quotes. Should %Q%N remove those quotes as well? This would break compatibility as well.

[Fla$her]

and no quotes are added during substitution of the %A placeholder. So it works as expected.

I didn't understand the meaning of what was written. What does "no quotes are added" mean? %A can contain quotes. Quotes should be suppressed after %Q. This is not happening.

%Q is not an option to remove quotes from a value.

And what else is it? I clearly remember what I requested.

It would break compatibility, which may cause problems for people.

What compatibility? %Q, like any parameter, is an optional thing. If you need quotes, don’t use the parameter. Isn’t that obvious? ¯\_(ツ)_/¯

[ghisler(Author)]

I didn't understand the meaning of what was written.

OK, It's best understood with an example.
1. Cursor on file name:
test file.txt
2. Button with command em_test and parameter %N
"test file.txt" is sent to em_test, including double quotes. If you don't want them, use %Q%N
3. Command [em_test] with command cd and parameter %Q%A
%Q tells TC to not add extra quotes, %A inserts the entire parameters received from the button, so
"test file.txt" is sent to the cd command.

[Fla$her]

2ghisler(Author)
You are essentially repeating the same thing. I explained everything to you, giving two examples where there is no %N, but there are texts, as well as %A1 and %A2. That is, your advice does NOT WORK! %Q%A is a rare case. Much more often, the work is done with different %Q%An.

I don't see any good reasons to ignore %Q for %An.
It was necessary from the start to suppress any quotes returned by parameters, not just those that appear because of spaces. This is a pointless limitation.

[white]

I didn't understand the meaning of what was written.

It seems clearly worded to me, so I have nothing to add.
For what it's worth, I will add an explanation by an AI model below. Perhaps it is useful to you.

1. What you actually requested in 2022
   You asked for a way to stop TC from automatically adding quotes around placeholders like %P%N, %N, %V, %S etc. when they are used inside larger command strings.
2. What ghisler actually implemented (TC 10.51)
   Exactly what you asked for: %Q suppresses the automatic addition of quotes during placeholder expansion for the following parameter.
   It was never designed (and never documented) as a feature that removes or strips quotes that are already present in a value.
3. Why your examples produce double quotes (this is expected behaviour, not a bug)
   Placeholder expansion happens in separate layers. This is the key point:
   

   Code: Select all

   Button bar (or command line) → expands first
   → passes the result to em_test as %A / %A1 / %A2
   usercmd.ini cmd= line → expands second
   

   When your button is em_test with parameter %N, the button layer expands %N first and adds quotes because the name contains a space. So em_test receives the value "1 2" (quotes are already inside the string).
   
   Then your usercmd line processes %Q%A. %Q only prevents TC from adding new quotes at this stage. TC is not adding any — it simply inserts the value that was already passed in. That is why the quotes stay and you get double quoting.
   
   The same thing happens when you run em_test "bla bla" from the command line or when you use %A1 / %A2 — the quotes are added in the previous layer.
4. This is exactly the same for %N itself
   If a filename on an FTP server (or any other plugin) literally contains quote characters as part of the name — for example a file named "testfile" — then %Q%N will still output "testfile" with the quotes included.
   %Q does not remove them, because they are not “added by TC” — they are part of the real filename. %A and %An follow exactly the same rule when they receive a value that already contains quotes.

%Q is not broken with %A or %An. It works exactly as it was designed and as you originally requested in 2022. The overquoting you see is simply the quoting that happened one layer earlier — not something %Q was ever supposed to undo.

If you want a new feature (“strip any existing quotes from the value of %A/%An”), that would be a valid feature request — for example a new placeholder like %~A or %Q~. But changing the existing %Q now would break many user commands that rely on the stable behaviour since 10.51.

[AntonyD]

%Q Turn off automatic quotation marks around certain parameters like %P%N when the name contains a space. The user will then have to place them by himself.

This is literally what is currently written in the help file. When we read it, we must also translate it. Into our language. After the fact.
We don't think in English. And after translating this one-line sentence - I, who had never used this parameter before (I had no reason to do so), absolutely and completely could not think that it does not work the way my colleague describes it above - namely: ANY string that has this parameter in its suffix will be processed according to the rule of this parameter - more precisely, all quotation marks will be removed (Turn off) from it. I am not interested in the reasons why the quotation marks are there. But the help still gave one single example as an example: because there was a space in the file name... That's all I could extract from the one-line comment in the help for this parameter.

In other words, to put it even more concisely - the parameter is needed ONLY for removing quotation marks. THAT'S IT.
You can't get anything else from this documentation.

So right now you are clearly trying to make something up with the help of AI from a forum discussion.
And yes, something like that might have been described there at some point.
BUT now the documentation gives a very unambiguous interpretation after translation - WHAT this parameter is needed for.
The CHM documentation does not contain those forum discussions.

[Fla$her]

It seems clearly worded to me, so I have nothing to add.

I also made myself clear enough. You're fixated on theory, while I'm only interested in practice. But neither you nor the author have responded to the practical comments yet.

For what it's worth, I will add an explanation by an AI model below. Perhaps it is useful to you.

It's not useful, because with AI, the context that the other person brings up is always important. He often borrows other people's thoughts without analyzing the real value of the solution.
AI has no understanding of the practical side of the issue, it produces superficial theses, clinging to false prompts and speculations.
I rate such quotes from AI as a tool of manipulation, nothing more. I advise you to abandon this practice.

But the help still gave one single example as an example: because there was a space in the file name.

Actually, it says "name", not "file name". In file system plugins, these may no longer be local file and folder names, but something completely different. Nevertheless, the parameters will work the same for any list items. %An in this sense differs only in that it may not return such names, but spaces can also be there, although this doesn't affect the result in any way.

By the way, my other request for em parameters (%A is also mentioned there), which is only a couple of months older, was actually supposed to become a trigger for revising %Q for any suppression of returned parameter quotes. It's good practice to fix something for the better, considering the additional functionality. It so happened that %Q was implemented before the em parameters, although the request itself came later.

[ghisler(Author)]

Sorry but we are getting nowhere with this thread. Even the AI has clearly understood that %Q prevents the addition of double quotes, it doesn't remove them. It even gave an example where the user entered em_test "bla bla" manually, with the double quotes. Here, %A now contains the string with the double quotes, and using %A does not magically remove these double quotes. The same happens with the button.

[white]

Sorry but we are getting nowhere with this thread.

Perhaps Fla$her can detail exactly what changes he wants made to TC. Then you can simply decide if you want to do that or not, or that he can make a suggestion post for that.

It seems that Fla$her wants to expand the function of %Q to include that values ​​inserted by the placeholder %A are stripped of surrounding quotation marks.

He claims that there is no compatibility issue because %Q can be left out. But the compatibility issue is of course when %Q is already being used in combination with %A (and other placeholders). A parameter can be anything and people may need the quotes being there. And people may be stripping the quotes themselves by removing first and last character (because their parameter is always quoted and unwanted). When %Q starts removing quotes, their commands will stop working correctly.

It's not clear if he thinks the Help text then needs to be adjusted as well, and to what.

It is also not clear whether he feels this new stripping behavior should apply only to %A, or to all placeholders and possibly environment variables.