Filename under cursor (%N) in Branch mode Produces filename with relative path

[aviasd]

Hi
When executing a command on a file in branch mode, %N produces the relative filename Including it's path
I.E for the command

Code: Select all

ExtractFirstWord %N 

Where %N is "Cleaners\CleanMyMac X.dmg"
I Get

Code: Select all

Cleaners\CleanMyMac

Expected:

Code: Select all

CleanMyMac

On non branch mode it works as expected..

Is this a Bug or by design ?

Is there an alternative % argument that works as I expect it to ?

[Gral]

Surprisingly with %n you can get what you want. Surprisingly as %n should return SHORT name, but in this case gives LONG name without path, what seems like a bug too.

[gdpr deleted 6]

Surprisingly as %n should return SHORT name, but in this case gives LONG name without path, what seems like a bug too.

I cannot confirm your observation about lower-case %n. Here, %n still provides short names in branch mode no matter what i try (as it should). If your observation was not mistaken, it's perhaps worth investigating what circumstances made your TC/button setup emit a long name for %n. I could imagine some unintended(?) interaction/dependency with some INI setting...

That said, lower-case %n indeed provides the (short) name without relative path. Taking into account the wording in TC's help ("%N places the filename under the cursor into the command line."), i would consider this the expected/intended behavior, and upper-case %N exhibiting a bug.

[aviasd]

I cannot confirm your observation about lower-case %n. Here, %n still provides short names in branch mode no matter what i try (as it should). If your observation was not mistaken, it's perhaps worth investigating what circumstances made your TC/button setup emit a long name for %n. I could imagine some unintended(?) interaction/dependency with some INI setting...

Hmm - I have this as well - Shortname gives me the long name without a path. I believe this is because I disabled at one point short name support .
You ccan check on your machine with :

Code: Select all

fsutil behavior query disable8dot3

If it's a bug for %N , %n is a good workaround for this specific use case , thanks

That said, lower-case %n indeed provides the (short) name without relative path. Taking into account the wording in TC's help ("%N places the filename under the cursor into the command line."), i would consider this the expected/intended behavior, and upper-case %N exhibiting a bug.

It's not only %N , Also %O And I'm guessing some more , but I didn't not test further...

So , *It is* a Bug ? How Do I move the thread to the bugs index ?

[gdpr deleted 6]

So , *It is* a Bug ? How Do I move the thread to the bugs index ?

I would say there is a bug here.

Even if uppercase %N behavior turns out to be intended behavior (which i personally don't believe, but you never know), there is still the issue of diverging behavior between %n and %N and other single-file-name parameters (which does not really seem intentional to me) to be addressed, plus a related issue when using %N and %M in conjunction with %X (see below).


So far, i can confirm the diverging behavior for:

%n / %N
%o / %O

The following parameters are not affected by the issue and seem to behave as expected:

%m / %M


There is an additional, related issue when using uppercase %N and %M in conjunction with %X in branch mode. When changing the meaning of %M and %N using the parameter %X, their behavior itself also changes depending on whether the panel %N (left panel) and %M (right panel) are referring to is the source/active or target/inactive panel. If the source panel matches the panel the parameter refers to, the parameter emits the file name with relative path. On the other hand, if the source panel is not that of the parameter, the parameter will only emit the file name without relative path.

Lowercase %n and %m in conjunction with %X do not suffer from this alternating behavior and always just emit the file name without the relative path, regardless of which panel is active.


You might have already noticed a pattern of behavior with the uppercase parameters here regardless of using %X or not not: In branched mode, they emit a file name with relative path when the panel the parameter is referring to is the source panel, but if the "parameter panel" is not the source panel only the file name is emitted. (%M alone will never emit relative paths because it always refers to the target panel. Respectively, %N alone will always refer to the source panel and thus always emit relative paths.) This makes little sense to me. Together with the lowercase parameters behaving as intuitively expected, this further reinforces my belief that the behavior of the uppercase parameters is the buggy behavior.



Thus, i'd like to ask the moderators to please move the topic into the bugs section.

[aviasd]

I confirm the above with %X%M/%X%N
In addition - %F does not exhibit the unexpected behavior (in branch mode)

[ghisler(Author)]

The behaviour of %N (relative path) is intentional. Why? %P returns the path shown above the file list. If the user then used %P%N, the file wouldn't be found if it is located in a subdirectory in branch view.

[gdpr deleted 6]

The behaviour of %N (relative path) is intentional. Why? %P returns the path shown above the file list. If the user then used %P%N, the file wouldn't be found if it is located in a subdirectory in branch view.

Are you saying that the behavior of the lower-case parameters like %n and %o is actually unintentional/buggy? Please clarify.

Also, why is this necessary for %N in respect to make %P%N working, while it is not necessary for %M in respect to make %T%M working?
%T%M works fine and proper, despite %M not including the relative path. It should be expected that %N and %M behave the same way (with the only difference being the panel they are referring to), because they do the same thing (aside from referring to a different panel). The current state of affairs is just confusing and inconsistent. I fail to see any rhyme or reason here, unless the intention was to confuse the user.

Anyway, ignoring my confusion and knowing now at least that uppercase %N behavior is intentional (as strange as it might be when considering the behavior of %M), it is worth noting that the help is incomplete about the behavior of %N. (The help currently only states that %N provides the file name, but apparently the intended behavior disagrees with the help. Making the help spell it out doesn't make the behavior more consistent across similar parameters, but at least it is then on the user if they don't RTFM.)


Please also read my last post here in this topic with regard to %X (in branch mode of course, as per context of this topic). It's all rather complicated for parameters which should exhibit a simple straightforward behavior that should not change based on hidden rules the user knows nothing about. Ideally, the %n/%N, %m/%M behavior in conjunction with %X should be made consistent (either always emit relative paths or always emit file names only, and no switching of behavior no matter which panel is active). But, if you want/need to stick with the current behaviors (your decision, and might very well be reasonable if these behaviors lurked in TC already for a reasonably long time), all aspects of the behaviors should be explained in the help (all the details, so a user will be able to fully understand what they are actually doing when crafting a toolbar button definition) and not left as a hidden surprise easter egg for the user to discover and troubleshoot...