Forums Bug Reports Paste bug?

I'm not sure if this is a bug or a feature, but either way, it's annoying as hell.

Say you try and paste:



You'll only paste:



Even if you try CTRL + ENTER while pasting it'll do the same.

*edit*

Tested on mIRC v6.21.

Strange. For me whenever Ctrl is held down when the paste takes place it treats everything as text. So using Ctrl+V always treats it as text but if you normally use Shift+Insert try Ctrl+Shift+Insert instead.

Note that Ctrl must be held down when the paste command is given, not when you press enter on the confirmation box (assuming you use the confirmation box on pasting more than x lines).

Has this just started happening with 6.21? I've only tested it on versions up to 6.2

Confirmed. This doesn't happen in previous versions.

When you use Control+V in a single-line editbox, all of the text you are pasting is parsed as a command if it begins with / or as normal text if not. So "/aliasname {" is parsed as a command.

When you use Control+V in a multi-line editbox, all of the text is entered into the editbox and you can then either press enter or Control+Enter.

Control should only be a modifier to force plain text when used with Control+Enter, as documented in the help file.

This was happening in 6.2 and possibly previous versions. Technically it was a bug since the Control key should only be a modifier when used with Control+Enter, not with the standard key combinations Control+V and Shift+Insert.

The problem is that in 6.21 there is no way, that I know of, to paste something as plain text if it begins with /. Ctrl+Enter+V doesn't work of course. So having Ctrl as a modifier for that doesn't seem like such a bad idea. In fact, it makes more sense to me:

Enter = interpret /lines as commands
Ctrl+Enter = don't interpret /lines as commands

Paste (Shift+Insert or rightclick) = interpret /lines as commands
Ctrl+Paste (which of course includes Ctrl+V) = don't interpret /lines as commands

The only problem is when somebody wants to use Ctrl+V to paste AND wants /lines to be interpreted as commands, but realistically, I think it's a non-issue.

You'd be surprised - on QuakeNet, lots of people use ctrl+v to paste the auth command from the email from Q, only to find that because they copied the trailing newline from the mail as well, their username and password end up on the current window (which is sadly often a channel).

That said, I miss the ability to paste commands as literal text as well..

i always use ctrl + shift + v to past commands to an channel and ctrl + v to execute commands in my mIRC Client

Confirmed. Couldn't find a way either and it's pretty annoying indeed. I think the old behaviour was better.

side note: since we are talking about paste bugs, i had one to bring to the table, if u have the setting to pop open the box on 2 or more lines, and u have one line in the clipboard but have a 013 or etc at the end, it still sends it to the chan, without the box, i was thinking that the next verison needs:

to remove that trilling crlf and treat it as one line

to detect it and pop open the box when that happens

Understanding that... but it would still be useful to be able to paste commands as literal text from a single-line editbox, which I believe most people use. So if you don't want to undo the "bugfix", can you think of any other way to accomplish this?

PLEASE add an option to select whether you want pasted lines starting with / to be executed as commands or pasted as normal text! And PLEASE make this option work for both multi-line or single-line configurations.

This has been a pet peeve for years of not just myself but also countless others. It's also the reason I registered on the forum... To make this request and beg Khaled on behalf of probably 90%+ of the mirc community.

Ps. And PLEASE make it so that when text is pasted, any leading spaces at the begining of a line are not discarded!

Thanks.

leading spaces are not discarded when pasting text containing cr/lf/etc on the end.

however, if you are using a script that catches input and echo's it the line differently (mirc themes or full scripts like invision for example) then they are lost purely because they must be run through the scripting engine.

I don't use such scripts. Or any scripts for that matter.

Then place two lines of text in an empty text file, with leading spaces, and hit enter at the end of each. Then copy to clipboard and paste them to yourself in pm.

Results:


Note that the first pair are me pasting the text into the query window, and the second are as recieved back from the server and shown by mirc.

Even when inline typing and hitting enter, leading spaces are not lost.

The bottom line is that the whole consequtive spaces / leading spaces issue with mirc is related entirely to the scripting engine, if your not manipulating the text as it goes out of comes in in any way then such spaces wont be lost.

Just to clarify, Invision will not remove spaces when using the Slow Paste from Clipboard option in the latest version(s) that we have released. Older versions did have a problem with that. This option prevents flooding and will not evaluate (or attempt to) variables, identifiers, commands, etc and will not remove spaces.

heh, other than a few months way back when it was called 'ultimate script' i have never really used invision longer than to take a look. Was just an example, used invision because its one of the most well know.

Heh, no problem. I was just clarifying for anyone reading the thread.

While it technically isn't leading spaces, if your text is -only- spaces, mirc will not print the line. IMO, it should.

What I do find strange is that I pasted a linux patch that was copied into my clipboard from Putty. I pasted it the first time and all leading spaces were removed. I pasted it a second time and it was normal so the problem appears to be intermittent.

Again, I do not use scripts so that clearly can't be the source of the problem.

At any rate, I care far more about mirc not trying to process / pastes as commands unless you tell it to. It should be an option as pointed out earlier.