Prefix processing now visually disturbing

[liqube]

Far Manager version

3.0.6600.0

OS version

10.0.19045.5965

Other software

For several builds now (it started somewhere in the late 5000s, not sure when exactly, but I can probably find out) plugin prefix processing is visually broken, even disturbing, since every prefix call briefly flashes the black console window.

This applies to all ways of invoking a prefix (e.g. "cd:" for named folders lite, or "audioplayer:filename"):

• directly by manual input at command line level + ENTER
• indirectly at command line level via macro/shortcut
• via any file association entry (for ENTER, F3, F4, ALT-PGDN, etc.)

FAR tries to execute the prefix as an actual command instead of understanding it directly (which was the behavior since the beginning of prefixes in FAR). The panels go away, we see the black console, then FAR does process the prefix and executes the associated action. However, the smooth processing is gone. Plugins now don't feel like they are part of the UI anymore, but we're running external commands.

I can share additional information or investigate further if needed.

Steps to reproduce

I have verified and reproduced this issue with a vanilla download of the latest x86/x64 builds (6600).
Any plugin that exposes any prefix will do fine for testing.
Just type its prefix at the command line and press ENTER.

Expected behavior

Plugin should open its dialog, or execute its action smoothly without the black console showing like it does for external commands. Only if the prefix is unknown should it be tried as an external command. But even then it doesn't make much sense to try it as an external command since ":" is an invalid character. So unless we have a single letter followed by ":" to change drive, the prefix does not need processing.

Actual behavior

Black console shows like it does for external commands, rather than processing the plugin's prefix directly.

[shmuz]

I totally support the idea that calling plugin by prefix should not cause those irritating panels blinking.

There is a workaround to behave as it always used to be: to start the command with @, e.g. @cd: <something>.
But IMHO the default should be inverse: calling plugin by prefix without @ should not make blinking.

[liqube]

There is a workaround to behave as it always used to be: to start the command with @, e.g. @cd:.

Oh I totally did not know that @ can silence the execution. I thought this only works for regular commands (batch style).
Thank you so much for sharing this.

It would be good to know why this was changed. From the changelog:

drkns 2017-12-19 23:12:07+00:00 - build 5110

1. Remove excessively smart processing of prefixes (rollback down to 1840), it also fixes G#11.

zg 2017-10-30 18:50:05+02:00 - build 5082

1. plugin prefixes are processed outside of launcher context.

drkns 2017-09-24 23:23:04+01:00 - build 5041

1. 0003501: Do not hide panels on launching a prefix according to association from command line

[liqube]

Just an additional observation:

When you execute a regular command like "cls" with a '@' batch-style silencer manually, via user menu, via association, or in any other way – even if it is the only command you execute – the panels will flash black with no output. This seems a bit counter-intuitive vs. silencing prefixes with '@'. It becomes especially obvious when you run a single command that does not need command line output (e.g. a GUI program, or a tool that does something quietly) from the user menu.