Problems with %$CLIPBOARD0% and %$CLIPNAME1%

[Fla$her]

I'll try to get through to Christian again here.

1. Select a file name on some Internet resource. Line breaks and spaces accidentally get there, as often happens:

Code: Select all

       File name.txt        
       

2a. Click the button with the cm_Edit /CGL0N="%$CLIPBOARD0%" and the file '_________File_name.txt' appears instead of 'File_name.txt'.
2b. Click the button with cm_Edit /CGL0N="%$CLIPNAME1%" and nothing happens.
It makes no sense to adjust the number in the button to an indefinite number of line breaks each time.

This complicates the user's work, because some sites create problems with accurate selection.

[ghisler(Author)]

The problem here is that you copied a line break in front of the name you tried to copy. Therefore %$CLIPNAME1% is empty.

I suggest that you use the following:

Code: Select all

cm_Edit /CGL0N="%$CLIPNAME1%%$CLIPNAME2%"

This way you will get the name either in %$CLIPNAME1% or %$CLIPNAME2%, and the other will be empty.

[Fla$her]

You are discussing the second problem, not the first.
The second problem is not solved on your advice, because:

1. there can be 2 or more line breaks, not one;
2. selection can be with the accidental capture of characters from another line.

If all edge line breaks and other whitespace disappeared, %$CLIPNAME1% would always return the correct string/name.

[ghisler(Author)]

You are discussing the second problem, not the first.

I only see one problem, using a file name copied from the browser. where is the other problem?

1. How? I never had more than 1 line break before the text when selecting text in a browser.
2. Yes, but the user can see this when selecting. Removing leading and trailing spaces from %$CLIPBOARD0% wouldn't help in that case either.

[Fla$her]

I only see one problem, using a file name copied from the browser. where is the other problem?

The first problem is described in point 2a ($CLIPBOARD0 + spaces), and you write about 2b.

1. It's strange to read this. For example, accidently. It also depends on browsers and site features (for example, some nested forms, tables, branchings, trees). Of course, as a compromise you could add additional commands like CLIPNAME_NE*/CLIPNAME_T* (NE = Non-Empty / T = full Trim) if you insist on the current behavior, but I'd definitely fix the whitespace problems right away.

2. I didn't understand what exactly the user can see when selecting?

Removing leading and trailing spaces from %$CLIPBOARD0% wouldn't help in that case either.

Why? If any '\n+\t+ +string +\t+\n+' is selected, the parameter will get only 'string'.

[ghisler(Author)]

The first problem is described in point 2a ($CLIPBOARD0 + spaces), and you write about 2b.

No, I describe how to solve the problem in your specific case. $CLIPBOARD0 is the wrong parameter here because it only replaces line breaks with spaces. $CLIPNAME0 would also not help because there would still be extra spaces for each line break. %$CLIPNAME1%%$CLIPNAME2% adds just the content of the two lines without spaces.
1. You can SEE what you copy when you select extra characters from other lines. Therefore these extra characters should not just be ignored by %$CLIPNAMEx% parameters.
2. The user sees the selected characters. He doesn't see any selected line breaks.

[Fla$her]

2ghisler(Author)
This is not my specific case, it is a common case for many users. Why reason from the point of view of a right-wrong parameter, if it is only about correcting their current behavior and making it the most user-friendly and accessible in relation to the command line? You can do this very simply.
In fact, when you added these variables, you were based on my suggestions in the topics. In its current form, this is not what I meant.
It's not always possible to see whitespace characters (I have listed the cases in parentheses). In addition, you force the user to aim, and this is an unnecessary waste of time and nerves, because if the user fails, he will again have to make a selection. What for? It doesn't make sense.

%$CLIPNAME1%%$CLIPNAME2% cannot solve the problem because this entry is not universal. You can choose both with empty lines and with non-empty ones, as a result, unexpected data will periodically arrive at the parameter.

1. This is a strange conclusion. It doesn't matter what I see. It is important to eliminate potential problems, i.e. an empty string or extra spaces for the parameter. We work with the command line, not just somewhere out there (like a text editor) with a clipboard. You have to understand this as a developer.
2. I wrote about random character capture, meaning the cases that I listed in parentheses. It often happens that you try to highlight one line from the beginning, and the browser grabs another one or two, and you don't see them.

In any case, the alternative solution remains in force:

Of course, as a compromise you could add additional commands like CLIPNAME_NE*/CLIPNAME_T* (NE = Non-Empty / T = full Trim) if you insist on the current behavior

[ghisler(Author)]

you could add additional commands like CLIPNAME_NE*/CLIPNAME_T* (NE = Non-Empty / T = full Trim)

I don't fully understand what they should do. First you said that I should ignore empty lines, but then you said that I should also ignore extra characters from other lines - but I have no idea what rules I should apply to decide between wanted and unwanted characters. For example, if there is a text

Code: Select all

The file was named
       File name.txt        
and contained the following data:

The user may want to select "File name.txt" to create a file with the data below it. But then the user somehow selects

Code: Select all

med
       File name.txt        
an

How should I know that the user only wants to have "File name.txt"?

If instead the user selects just

Code: Select all

 
       File name.txt        
 

with an accidental line break before and after the name, the case is 100% clear. But in that case, %$CLIPNAME1%%$CLIPNAME2% already works, there is no need for any extra parameters! So I don't really understand what CLIPNAME_NE*/CLIPNAME_T* should do.

[Fla$her]

I missed the answer. I just saw it.

First you said that I should ignore empty lines, but then you said that I should also ignore extra characters from other lines - but I have no idea what rules I should apply to decide between wanted and unwanted characters.

Initially, we talked only about white space characters [ \f\n\r\t\v], which are unnecessary.

I quote:

Also, deleting all edge blank lines should also apply to %$CLIPNAME1%, %$CLIPNAME2%:

Code: Select all

        
   
   Name 1   

     Name 2     

Name 3    

%$CLIPNAME_NE1%=Name 1
%$CLIPNAME_NE2%=Name 2
%$CLIPNAME_NE3%=Name 3

In your case it will be like this:

%$CLIPNAME_NE1%=med
%$CLIPNAME_NE2%=File name.txt
%$CLIPNAME_NE3%=an

The quote you quoted already contains the answer: NE = Non-Empty / T = full Trim

But you can also consider a better solution with the removal of all forbidden characters at the edges:

Code: Select all

   |    
 <Name1>   *

 <Name2>   ?   
"Name3"


Name4:  

  \

 /  Name5  \

>>>
%$CLIPNAME_T1%=Name1
%$CLIPNAME_T2%=Name2
%$CLIPNAME_T3%=Name3
%$CLIPNAME_T4%=Name4
%$CLIPNAME_T5%=Name5

[ghisler(Author)]

Thanks for the explanation. For now I will implement skipping empty lines (or those containing spaces) with %$CLIPNAME_NE1%.

[Fla$her]

And what will it return if the string contains only the forbidden character or characters?

[ghisler(Author)]

Forbidden characters are being converted to underscores, as described in the help:

replaces the characters *?|<> that are forbidden in file names with underscores_

[Fla$her]

That is, instead of '|', the name will be '_', and instead of '*?|<>' will be '_____'? And why do we need such names?
And what will happen for quotes and colons?

[ghisler(Author)]

And why do we need such names?

This is mainly meant to replace single characters in a name which would otherwise make it impossible to save as a file.

And what will happen for quotes and colons?

I can't remove them (just like backslashes) because they have their purpose:
- quotes can be used to surround a name with spaces
- colons are used when specifying a full path.

[Fla$her]

This is mainly meant to replace single characters in a name which would otherwise make it impossible to save as a file.

I have nothing against these characters being replaced with underscores inside valid characters. I only suggested getting rid of the end ones together with the whitespace ones. I.e. | ? File<Name?.ext*> | > File_Name_.ext

- quotes can be used to surround a name with spaces

I disagree. The user himself must control quotation marks by specifying them in the parameters, otherwise there may be difficulties with incorrect selection, for example, when one quotation mark is selected or when a string with spaces without quotation marks is selected. That is, if I set the "%CLIPNAME*" parameter, the result may be ""Name"", "" Name "", ""Name", "Name"", "" Name ", " Name "", etc., although there should be only one, "Name". If you set the parameter without quotes, then the following: " File name ", " File name, File name ", not File name. All this will lead to incorrect operation of commands.
Also keep in mind that %Q doesn't work on pseudovariables.

- colons are used when specifying a full path.

You can easily control this by checking the beginning of the line for [A-z]:\\. In other cases, the colon can be replaced.