FarManager
FarManager copied to clipboard
FarGroup
Draft for new metasymbols:
-
!<- refers to the left panel -
!>- refers to the right panel
In comparison with the existing !# and !^ metasymbols, the new ones allow to pass files from both panels in their fixed order: the name from the left panel first, then the name from the right panel.
Re changes: IMHO the suggested help text lacks (1) references to Note 4 in each of new symbols' description and (2) mentions of the new symbols in the Note 4 itself.
I thought about it. Even my first edition to the help text had already (1) and I was going to add (2). But I decided to remove any cross-referencing between the main text and the note 4.
The main reason is that !# and !^ act in more complicated way - they can toggle metasymbols multiple times. For instance, !##!\\!^!.!.
In the other hand, !< and !> are assumed acting only once: to point that the following symbols come from the left or right panel, correspondingly. That's why I added the couple of comments to the .cpp file - I wasn't sure in necessity of initializing the property SubstData.PassivePanel for new symbols.
And thank you for the link to the forum discussion.
@ildar-shaimordanov Could you please clarify the intended behavior? Should new metasymbols apply to the file spec they are attached to, or to rest of the command line? Assuming the file left.active.file is currently selected on the left panel, the file right.passive.file is selected on the right panel, and the left panel is active, what the following command will print?
echo !>!.! !.! !^!.! !<!.! !#!.!
@MKadaner
To the file spec only.
The main purpose of new symbols is to refer to the particular panel explicitly or even straightforwardly, with no any reflections on active or passive panel it is.
and the left panel is active
!>!.! - right.passive.file, from the right panel explicitly
!.! - left.active.file
!^!.! - left.active.file
!<!.! - left.active.file, from the left panel explicitly
!#!.! - right.passive.file
Let's consider that the active panel is changed and it's right panel now:
!>!.! - right.active.file, from the right panel explicitly
!.! - right.active.file
!^!.! - right.active.file
!<!.! - left.passive.file, from the left panel explicitly
!#!.! - left.passive.file
You can see that !# and !^ change expanded values every time panels change their activity/passivity.
New symbols !< and !> are assumed to be independent on the panel's activity/passivity state.
@ildar-shaimordanov What you describe means the new symbol will affect only one following symbol. Is it really what the implementation you suggest gives? In this case, e.g. !<!\!.! will mean path from the left panel followed by the file name from the active panel. Does it indeed work this way? If yes, then the documentation has to be amended to mention only the following symbol rather than all subsequent ones. And if not, then my initial suggestions hold.
Ideally, please make the exact experiment suggested and paste the result.
OK. Wrong question. Sorry. Let's try again. I added the following test script to the user menu:
dir /b !\
dir /b !#!\
echo !# blah !.! !.!
Left panel is active. Here is the output:
>dir /b D:\DEV\Test\left.folder\
left.file
>dir /b D:\DEV\Test\right.folder\
right.file
>echo blah right.file right.file
blah right.file right.file
What is expected output of this command:
echo !# !.! !< !.! !.!
Or this:
echo !# !< !.! !.!
Or this:
echo !< !# !.! !.!
Other variations on this theme? Could you please test it on your implementation?
It's not an idle question. I will happily write help article for this new feature, both English and Russian, but I need to understand the behavior precisely.
@HamRusTal, @MKadaner
I am going to answer both of you in this post.
After reviewing the code I suggested to discuss and implement I found that it should act the same way as !^ and !#. And it is not follow the description I gave previously.
Few days ago I tried to compile FAR using the latest version of MinGW but I'd got the weird error that stddbg.h file is not found. I expected that this file should be in place after installing MinGW. I am not familiar with C and I need more time to recognize the root cause.
