%Q doesn't work with %A

[ghisler(Author)]

A parameter can be anything and people may need the quotes being there.

Exactly - the user may have two buttons,

Code: Select all

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

and

Code: Select all

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

Here the first would pass the name to em_test with double quotes, and the second would pass the name without them.

Moderator message from: ghisler(Author) » 2026-04-22, 10:47 UTC

Moved to will not be changed

[Fla$her]

Even the AI has clearly understood that %Q prevents the addition of double quotes, it doesn't remove them.

I've already made it clear why you shouldn't trust AI. I have provided a link to my request, where suppression, not prevention, is stated directly in the title.
In other words, the current implementation does not fully satisfy the purpose of my suggestion.

It even gave an example where the user entered em_test "bla bla" manually, with the double quotes.

You know that this user is me. And with this example, I made it clear that there is no direct connection here with %N or a similar parameter, i.e., it can also be a matter of manually specifying quotation marks. The AI is not unable of correctly assessing the context here; it lacks the depth of analysis of the hidden details of the initial goal setting. It considers the extracted text superficially.

Here, %A now contains the string with the double quotes, and using %A does not magically remove these double quotes.

This should be done by %Q in front of it, not by %A.

Let's look at the logic of the suppression (not prevention) I requested:

Parameter where quotes for spaces are added automatically → parameter that suppresses quotes before it → result: returned text without quotes
Parameter where quotes for spaces are added manually → parameter that suppresses quotes before it -> result: returned text without quotes

That is, the difference here is only in the words "automatically" and "manually". What's the point of complicating a program's algorithm by checking for automation, which does more harm than good? Wasn't it logical to do it this way initially?" →

Parameter where quotes for spaces are added automatically or manually → parameter that suppresses quotes before it → result: returned text without quotes

This would immediately give the desired result, and we wouldn’t have to return to this task now.

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. ... When %Q starts removing quotes, their commands will stop working correctly.

You've fallen into theory again. These are all purely hypothetical things that you, I'm sure, will not find in practice anywhere or from anyone. You are trying to dig in a very solid place where the shovel rests against common sense.

The very need to suppress quotes for %An is related to the command syntax of other programs, where double quotes are needed only to enclose the entire entry. This was reflected in the examples of the original post of my proposal. I don't see any practical logic in the fact that, with such syntax, it's necessary to keep double quotes for parameters located, for example, after "%Q'%A1' %A2' %A3'".
However, I have already raised the issue of applying %Q only to the conjugate parameter (like %X) or adding one that would stop its action. Nothing has been done so far.

And people may be stripping the quotes themselves by removing first and last character (because their parameter is always quoted and unwanted).

Unfortunately, I cannot assess the depth of this thought without a working example.

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

I would insist that the word "automatic" be removed from there after bringing the work into proper form.
As a last resort, it could be %q, which does what is required. But only in the current version, so as not to wait a long time for such em commands to finally work.

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.

%|EnVar|? This would be logical, although much less in demand.

Please return the topic to the original section.

[white]

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. ... When %Q starts removing quotes, their commands will stop working correctly.

You've fallen into theory again. These are all purely hypothetical things that you, I'm sure, will not find in practice anywhere or from anyone. You are trying to dig in a very solid place where the shovel rests against common sense.

First you suggest that there is no compatibility issue. Now you say that there is, but suggest that it isn't used anywhere by anyone. Yet, you start this thread with an example of exactly that, and there is no reason why anyone shouldn't use something similar to that.

However, I have already raised the issue of applying %Q only to the conjugate parameter (like %X) or adding one that would stop its action. Nothing has been done so far.

When the function of %Q is expanded to mean strip surrounding quotes from any final value inserted by any placeholder, that certainly seems more relevant.

And people may be stripping the quotes themselves by removing first and last character (because their parameter is always quoted and unwanted).

Unfortunately, I cannot assess the depth of this thought without a working example.

Your example from the first post, but adjusted a bit:

1. Create a command in usercmd.ini:

   Code: Select all

   [em_test]
   cmd=cd
   param=?%Q%A1:~1,-1 %N

2. Create a button:

   Code: Select all

   TOTALCMD#BAR#DATA
   em_test
   %Q"%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.

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

I would insist that the word "automatic" be removed from there after bringing the work into proper form.

That would leave a very poorly worded description of what you seem to want.
It seems you want convey the removal of outer quotes from any inserted value by a placeholder, in contrast to the current implementation: to disable that quotes are automatically added to filenames and paths when they contain one or more spaces.
As mentioned before, it is possible that the filename itself contains quote characters. Are you suggesting an implementation where these quote characters will now be stripped from the produced filename?

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.

%|EnVar|? This would be logical, although much less in demand.

Well, make a decision. You suggest a change, so be clear about what you suggest exactly.

[Fla$her]

but suggest that it isn't used anywhere by anyone.

Suggest? I'm sure about this and explained why.

Yet, you start this thread with an example of exactly that, and there is no reason why anyone shouldn't use something similar to that.

I gave an example solely for testing purposes, to quickly reproduce the bug, as many do here. It has nothing to do with practice.
I put %N there just to show that some parameters will have quotes and some won't. That's all.
There are actually no technical reasons to use this directly.

When the function of %Q is expanded to mean strip surrounding quotes from any final value inserted by any placeholder, that certainly seems more relevant.

And this solves the hypothetical compatibility problem.

Your example from the first post, but adjusted a bit:

I already wrote that it's a test example, not a working one (used in work).

%A1:~1,-1

Ah, that's what you meant. I didn't even think about that. Hmm. Now it's clear, but it looks like a workaround, not a beautiful solution, given that there may be several such entries ":~1,-1" in commands.
But anyway, thanks for the tip.

As mentioned before, it is possible that the filename itself contains quote characters. Are you suggesting an implementation where these quote characters will now be stripped from the produced filename?

On Windows systems, double quotes in names are prohibited. TC was not written for other OS.
Given %A, there can be any substrings except for file names. And the quotes must be suppressed (as requested), not prevented.

Well, make a decision. You suggest a change, so be clear about what you suggest exactly.

I don't suggest, I have already suggested (requested) this before creating %Q. It doesn't matter which %<parameter> will include quotes, the main thing is that it works equally for everyone.

[white]

Yet, you start this thread with an example of exactly that, and there is no reason why anyone shouldn't use something similar to that.

I gave an example solely for testing purposes, to quickly reproduce the bug, as many do here. It has nothing to do with practice.
I put %N there just to show that some parameters will have quotes and some won't. That's all.
There are actually no technical reasons to use this directly.

They are no technical reasons why people shouldn't use something similar to that.

However, I have already raised the issue of applying %Q only to the conjugate parameter (like %X) or adding one that would stop its action. Nothing has been done so far.

When the function of %Q is expanded to mean strip surrounding quotes from any final value inserted by any placeholder, that certainly seems more relevant.

And this solves the hypothetical compatibility problem.

No, that implementation doesn't solve it.

As mentioned before, it is possible that the filename itself contains quote characters. Are you suggesting an implementation where these quote characters will now be stripped from the produced filename?

On Windows systems, double quotes in names are prohibited. TC was not written for other OS.

Not exactly a clear answer, but I think you mean a change in behavior and that quotes will be stripped from the name in this case. I am against that change.
TC supports connecting to other filesystems for ages. It even has a plugin system for other filesystems.

Given %A, there can be any substrings except for file names. And the quotes must be suppressed (as requested), not prevented.

All quotes, or just one set of surrounding quotes?

Well, make a decision. You suggest a change, so be clear about what you suggest exactly.

I don't suggest, I have already suggested (requested) this before creating %Q. It doesn't matter which %<parameter> will include quotes, the main thing is that it works equally for everyone.

Again, not a clear answer. Do you also want to strip quotes from values inserted by environment variables, or not?

[Fla$her]

They are no technical reasons why people shouldn't use something similar to that.

Without technical reasons, one can even walk on the head. Who's stopping?
There is such a thing as expediency. It either exists or it doesn't.

No, that implementation doesn't solve it.

And why is that? No neighboring parameter will suffer when it's necessary to suppress quotes only for %A.

Not exactly a clear answer, but I think you mean a change in behavior and that quotes will be stripped from the name in this case. I am against that change.

Then you should have disputed this 4 years ago, not now. Or maybe even earlier.

TC supports connecting to other filesystems for ages. It even has a plugin system for other filesystems.

What is a plugin system?
Again, give an example with such a file system and %Q. What do you want to achieve in interacting with names where %N returns "1" 2 "3"?

All quotes, or just one set of surrounding quotes?
Do you also want to strip quotes from values inserted by environment variables, or not?

Don't you think these questions would be appropriate for a completely different section? I asked to move the topic.

[ghisler(Author)]

Sorry, I don't see why %A should ever remove double quotes. %A stands for the ENTIRE command line, so it will often contain multiple parameters - and they come in double quotes if they contain any spaces in names. It could be helpful for individual parameters like %A1, which on their own can be in double quotes or not, so it may be useful to add/remove double quotes. But this would be a completely new parameter, it has nothing to do with the description of %Q.

%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.

As you can see, all %Q does is turning OFF the automatic addition of quotation marks around %N or %P%N. It does nothing on its own.

[Fla$her]

2ghisler(Author)
It feels like you are talking about a parameter that you implemented according to your own idea. But, as I explained above, the original task of my old thread was to suppress any internal quotation marks in order to enclose them in general ones, but for some reason you ignored this and only implemented quote prevention, which is not the same thing.

As for the new parameter, how long should we wait for it? Did you see what I wrote about it? ️

As a last resort, it could be %q, which does what is required. But only in the current version, so as not to wait a long time for such em commands to finally work.

[ghisler(Author)]

If %q is meant to remove double quotes from every parameter, then it's nothing I can add quickly over night - it would require months of beta tests again to find all possible parameters which could come with double quotes, like environment variables and such.

[white]

However, I have already raised the issue of applying %Q only to the conjugate parameter (like %X) or adding one that would stop its action. Nothing has been done so far.

When the function of %Q is expanded to mean strip surrounding quotes from any final value inserted by any placeholder, that certainly seems more relevant.

And this solves the hypothetical compatibility problem.

No, that implementation doesn't solve it.

And why is that? No neighboring parameter will suffer when it's necessary to suppress quotes only for %A.

As said before, people's buttons etc. that already use both %Q and %A in the parameter field will break. That's the compatibility issue. It isn't solved by your suggested implementation here.

As mentioned before, it is possible that the filename itself contains quote characters. Are you suggesting an implementation where these quote characters will now be stripped from the produced filename?

On Windows systems, double quotes in names are prohibited. TC was not written for other OS.

Not exactly a clear answer, but I think you mean a change in behavior and that quotes will be stripped from the name in this case. I am against that change.

Then you should have disputed this 4 years ago, not now. Or maybe even earlier.

The linked suggestion by petermad describes exactly the current implementation. It does not strip quotes that are part of the filename itself.

All quotes, or just one set of surrounding quotes?
Do you also want to strip quotes from values inserted by environment variables, or not?

Don't you think these questions would be appropriate for a completely different section? I asked to move the topic.

Sorry, I don't see why %A should ever remove double quotes. %A stands for the ENTIRE command line, so it will often contain multiple parameters - and they come in double quotes if they contain any spaces in names. It could be helpful for individual parameters like %A1, which on their own can be in double quotes or not, so it may be useful to add/remove double quotes. But this would be a completely new parameter, it has nothing to do with the description of %Q.

2ghisler(Author)
It feels like you are talking about a parameter that you implemented according to your own idea. But, as I explained above, the original task of my old thread was to suppress any internal quotation marks in order to enclose them in general ones, but for some reason you ignored this and only implemented quote prevention, which is not the same thing.

Exactly, it is not the same thing. The current implementation works as designed, but you want something different. That makes it a feature request. And you still haven't clearly said what this feature should do exactly.

[Fla$her]

If %q is meant to remove double quotes from every parameter, then ...

What do you mean by "every parameter"?
%q%N %N %q%V ➙ name 1 "name 1" C:\path to\name 1
or
%q%N %N %V ➙ name 1 name 1 C:\path to\name 1


2white
Why such an excess of quotes? I never lose the thread with short excerpts from the text.

[ghisler(Author)]

What do you mean by "every parameter"?

You want me to remove quotes from %A with %q, but %A is the entire command line, e.g.
"file 1" "file 2" /switches
Now what should %q do in such a case? There are no surrounding quotes for %A, but for individual parameters like:
%A1 -> "file 1"
%A2 -> "file 2"

[Fla$her]

If we use em_, then it's obvious that %q%A will be applied equivalently to %q%A1, i.e. it implies writing a single parameter. With multiple parameters, using %q%A is pointless, there will be %q%A1 %A2 .. %An.

%A1 = "text 1"
%A2 = "text 2"
%A3 = "text 3"
%A4 = "text 4"

%q%A1 %A2 %A3 %A4 = text 1 text 2 text 3 text 4

And in the vast majority of cases, this will be enough.

MVV proposed to expand this:

I would request third mode: always quote, I know that it will be useful. And I would name it %Q<x>, where <x> is mode (letter or number, no matter, e.g. %Q to reset, %QA to always quote and %QN to don't quote).

But I think a toggle parameter would be a universal solution:

%q%A1 %q%A2 %q%A3 %q%A4 = "text 1" text 2 "text 3" text 4

This, by the way, would be useful for %Q as well.

What do you think?

[ghisler(Author)]

Thanks for the suggestions, sounds all reasonable for %Ax parameters. It's still not clear what %q%A should do.

I would request third mode: always quote

I don't think that this is necessary because you can just remove/not auto-add quotes and then add your own, e.g.
%Q"%P%N"
for how it currently works with %Q.

[Fla$her]

It's still not clear what %q%A should do.

I don't think there is a need to process any parameter separately here. Let's assume there will be any parameters with quotes: %A %N %|EnVar|, etc.
The task is to suppress the quotes in the required area, which will be defined by two %q:
"-par1 '%q%A' -par2 '"%O"' -par3 '%|EnVar|'%q"
I specifically indicated "%O" here to account for any source of double quotes. For this reason, the last %q is placed here before ", not after.
This means that you won't have to process each parameter separately, you will just remove all the quotes in the string between the two %q.
Every first %q in the pair will simply remove all double quotes until the next %q.

I don't think that this is necessary

This is not in my suggestion. I have given the quote only as an example to outline the general context.