Forums Bug Reports Paste bug?

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!