• When you select text in the command window, any selected text in the output window is automatically deselected.
  
  
• When you select text in the output window, any selected text in the command window is automatically deselected.
  

Well, let's work through why it behaves that way so we can discuss the best way around it.

Each MUSHclient world has two main windows - the upper (output) window, and the lower (command) window.

Each window can have the "focus", which is where the problem starts. They both need to have the focus because both can have selected text, see image:

The relevant question here is, if I select Edit -> Copy or press Ctrl+C, what gets copied to the Clipboard? Is it:

• "The illustrious Darkhaven Academy Headmistress"; or
• "greet Mistress Tsythia"

The answer would seem to be "whichever window has the keyboard focus".

The problem is, if you select text in the upper window, with a view to copying it (and indeed after copying it), the focus is still in the upper window.

In early versions of MUSHclient, if you then started typing (eg. "north", "open door") your typing would be swallowed up because the upper window is an output window.

An early work-around was to make you press a key to return focus to the lower window. Both <tab> and <esc> were provided as handy and easy-to-hit methods.

In those versions, Ctrl+C worked in a "natural" way, however it was annoying if you clicked on MUSHclient to bring it to the front, by clicking on the output window (the larger one), and then found that what you typed had been thrown away.

Hence the invention of "all typing goes to the command window" was born. With this active, the program intercepted key events (like the letter "a") and before doing anything else, put the focus in the command window. Then the event was allowed to continue, with the focus now in the correct place.

At this point I think Ctrl+C still worked, because some keys are not, strictly speaking, characters (eg. F1 does not have a character equivalent, like "z" or something).

The inbuilt macros (like F2, F3, F4 etc.) worked because special provision was made for them. In the output window handlers were put in place for all the macro keys. These handlers set the focus to the command window, and then let the macro function normally.

I think the whole problem probably started around the time that you were allowed to make your own accelerator keys (with the Accelerator script function). Now it was possible to define key events (eg. Ctrl+Right-arrow) that do not generate character events, and thus did not shift the focus to the command window.

To work around this, the "all typing goes to the command window" functionality was altered to not just detect character events (like letters or numbers) but all keydown events. This fixed the problem with user-defined macros, because the moment you hit a key (like Ctrl) the focus shifted to the command window.

However this now caused the problem with the Ctrl+C, because as you type Ctrl+C the Ctrl key shifts the focus to the command window, and then by the time it has seen the "copy" command it copies from the command window and not the output window.

I developed a plugin a while ago that tried to work around that - if there was text selected in the output window, but not the command window, then Ctrl+C used the output window, otherwise it used the command window.

I'm not sure there is a better way. Maybe the functionality of that plugin could be incorporated into the client, but it would still depend on having text selected only in the output window.

Just changing things back to how they were is likely to bring screams of protest that user-defined accelerator keys "don't work sometimes".