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.

Ok, this is very different, pasting/inputting only spaces is a completely different story. I do believe that sending a raw to the server (or the server sending one back or to you) in which a required token of the raw is all spaces, would break protocol standards?

Hi Khaled,

I like multiline editbox very much because I often write long messages, and like to see back on the last sentence when I write the current. Often, when writing complex reasoning I need to edit something I wrote in some sentences back, and when done this, I'm ready to send, but I can't push [Enter] with any other effect than producing CRLF. Not that I don't like the possibility to split one textbox text into more messages. This is a great property. But I also want to be able to send fast, without moving the cursor to the end of the textbox. I also want to be able to move fast to the start and to the end of a text in a textbox. If you could put in a ctrl + Enter function that sends the text no matter where in the text the cursor is, that would be nice. And if you could make ctrl + home to go to the start of the editbox, and ctrl + end, to the end, that would be nice too, instead of as now, when ctrl home/end control the channel pane. And in addition to this. When writing a long message, it would be nice if it was possible to put a CRLF to split a text into more messages with shift + Enter instead of ctrl + shift + ENTER. Two control keys is kinda quirky for such a common functionality. ctrl + shift + home/end could control channel/pm panes. That is kinda rare you want to do anyway.

Another thing, when scrolling back in a *single-line box*, the text you're about to write, doesn't disappear, but it does when scrolling back with ctrl + arrow up/down in a multiline textbox. That is, when the text you are about to write is of more than one line. (you have used ctrl + Enter) When returning back from scrolling the message buffer, only the first line is there.

A third thing. Could you make more lines in that multiline textbox you think? Well, I like to write long messages:-)

Not that this is relevant in this context either, if it's breaking the protocol or not, because, when using /raw, the whole point is to break protocol standard. When using initial spaces, mIRC should send it, but it doesn't. It's stripped. The funny part is that when you try //raw PRIVMSG $me mirc does indeed what it supposed to, try to send a message without any content:-) This is okey, but not spaces.

I guess this is about Khaleds thing about spaces. I think he hates them. Specially in file names, and if they are more than one put together:-)

This is my favorit:

//write " $+ $mircdir $+ \ $+ te $+ $chr(32) $+ $chr(32) $+ st.txt $+ "

You never find that file:-)

An IRCD does not allow you to send empty PRIVMSG's (several spaces with nothing else is concidered empty by the server). So why should a client like mirc even attempt to send a privmsg with an empty text token (the protocol rfc requires the token, its not optional, and spaces-only is never concidered a valid token since they are the delimiters)

both "/raw privmsg SomeNick :" and "/raw privmsg SomeNick : " correctly return a 'No text to send' response from the ircd. It would be silly for mirc to send a raw, through an event, that it knows is wrong.

PS. You are completely wrong, the point or existance of /raw and /quote has absolutely nothing to do with 'breaking the protocol standard'

If it is that important for you to even try and send an empty privmsg, then script it.

on *:INPUT:#: if (!$1) { /echo -a nothing to send but lets force it to send an empty raw anyway | /raw PRIVMSG # : }

I don't know what these last few posts have to do with the paste problem but I have a comment anyway...



It's the ircd's job to accept/reject messages. Not to mention many people run modified servers that allow all sorts of things. Mirc should not place such limitations and add unnecessary code. It should simply attempt to send what the user is trying to send. If the server accepts it, great. If not, oh well I guess.

Servers accept messages consisting of spaces only anyway. The reason you get a "No text to send" reply when using /raw is that /raw strips those spaces itself, ie doesn't even send them to the server. One can verify that spaces-only messages are indeed accepted by typing a bunch of spaces in an editbox and hitting Ctrl+M (with no on INPUT events interfering of course).

Give me ONE good reason why mIRC should knowingly send a raw (not from /raw or /quote) that is missing required information (the actual message) and furthermore why it should print a spaces-only line in the window when typing and hitting enter in the editbox.

If you really must have empty lines hit ctrl+o then enter, for all intensive purposes it will seem just like an empty line.

" " is just as valid of a message as "aaaaa". As I said, mirc should not be restricting anything, it should attempt to send what the user is trying to send and it's up to the server to decide if it accepts/declines it.

I'll pose a question to you now... Give us just ONE good reason why mirc should restrict any message a user is trying to send. A real reason, and not a personal opinion such as 'spaces are not a message'.

The bottom line is mirc should not be dictating what a user sends in his messages.

I agree that mirc should not dictate what can be sent in a message, however i dont believe that a delimiter and a token should be allowed to be the same. I see this more as a syntax verification than as a filter/censor. But to each there own.

Originally Posted By: Om3n

for all intensive purposes

for all intents and purposes?

Well it looks like this still hasn't been address so maybe in the next version... Whenever that comes.

Very good idea. Hoping to see this in a future version.

i wanted to bring this issue back into light, since this is a paste bug thread, i wanted to do it here, no use making a new thread.

Please FOR THE LOVE OF GOD do not let this thread die!!!

To bring forward arguments already given? To inc it's counter? To me, a thread dumped like that (without any new argument/info/opinion) appears quite dead

It's not dead until the problem is fixed!