Prevent mcedit from hanging on macro

[jtyr]

Summary

Fixes editor hang when executing macro scripts via mc -e.

Problem

Running MC in editor-only mode (mc -e file) and executing a macro script (e.g., via edit_block_process_cmd) causes the editor to hang indefinitely.

The hang occurs in invoke_subshell() in src/subshell/common.c. Before sending a command to the subshell, the code sends Ctrl-C to clear any leftover input and calls feed_subshell(QUIETLY, FALSE) to wait for the shell to reach a prompt. This wait relies on the shell's prompt hook writing its CWD to a pipe - but in editor-only mode (MC_RUN_EDITOR), use_persistent_buffer is FALSE and the shell's CWD-reporting hook is not active, so feed_subshell blocks forever on select().

Fix

Skip the Ctrl-C + feed_subshell pre-clearing when not in full MC mode. This code path exists to clear user-typed text from the subshell prompt before injecting a command - but in editor mode, the subshell has not been interacted with by the user, so there is nothing to clear.

Test plan

• mc -e somefile - select a text block, run a macro script - should execute without hanging
• Full MC mode - run mc, edit a file (F4) and run a macro script - should work as before

[mc-worker]

Please add a detailed info to the commit message.

[GfEW]

Just to be sure what looks like an oversight to me here is only due to my own lack of understanding:

Does that "subshell" refer to the visible prompt line that's by default shown below the panels in plain mc and absent from mcedit, mcview and mcdiff, or rather to the subshell that's toggled with C-o in mc , mcedit, mcview and mcdiff alike?

[ossilator]

it's the same subshell, just presented differently. the comments in the surrounding code imply this pretty strongly, so i guess you didn't look very hard.

with some minor adjustments (omitting the "meta" stuff), the PR description would make a fine commit message.

there should be a code comment explaining the conditional concisely, like the other ones.
the nesting of the conditionals is debatable, but that's a pre-existing problem.

@egmontkob was poking this code most recently, so he may have a more profound opinion.