Forums Feature Suggestions Stop script removal of double/embedded spaces

Note: I could not see this having been mentioned before, so dont flame me if it has :P.

Would it be possible to stop mIRC from stripping embedded double spaces when processed through a script. For example:


Comes out as

h e ll o

With only single spaces where I want multiple ones. I can't work out a way to force mIRC to buffer it out either.

Is this what you mean?

If you do a Search for "spaces" and expand to 'All Forums' and expand the date range to 'All Posts' you'll see a number of threads mentioning the space issues experienced from /echo and /aline.

Happy chattin

Regards,

The only discussion of it in the last 6 months in Feature Suggestions is the link you gave. The link you gave also happens to be one of the worst threads ever. The guy suggested supporting consecutive spaces and you've got a couple of guys complaining that he dared suggest such a thing and a bunch of others listing 101 bad scripting hacks that try (and fail) to accomplish the same thing. It would be nice if there was a *good* thread on the subject in the Feature Suggestions forum.

I'd like to see consecutive spaces supported.

As far as scripting with them goes I think $n should remain the same since allowing $null tokens would break a lot of scripts. It would be better if it was supported as another identifier, either as a single $fulltext or a set like $textn. Personally I prefer the $textn example (assuming it supported ranges like $n does).

hence the advice to expand to 'All Forums' and 'All Posts' with a search for "Spaces" - Despite the bickering that occurs in that thread (which isn't particuarly bad bickering compared to what else I've seen) it does provide info on the issue and it seems that DaveC's workaround did work for that user, although I have not looked at it in detail though.

Agreed however, there should be a better thread to refer to, so GJ for getting the ball rolling *G*

Regards,

there would have to be extra work done for it, maybe a switch on the echo's , since its a known thing that multiple spaces are removed, and people knowing that have used it in all types of places, just changing it wont go down to well.

If you want to get mutiple spaces into a line try this cheap trick in front of each space press ctrl-b twice.

bold on bold off, or bold off bold on, which ever the case is.

When do people ever rely on /echo stripping spaces for something to work?

well i have for a start

echo All $numtok(%r1 %r2 %r3 %r4 %r5,32) Result(s) listed here $eval(%r1 %r2 %r3 %r4 %r5,1) $+ .

I wouldnt wont extra spaces all over that

but more i was refering to this.


people im sure rely on the fact that multiple spaces wont be added in just becuase they happen to be in the script. Even if they are just cosmetic for reading etc.

ex.

I don't see how multiple spaces would affect that first script.

As for the second, well to me that just seems like bad practice. Surely it must be obvious that the possibility of mIRC supporting consecutive spaces is always there, so anyone who intentionally does something which risks being broken by that purely for some minor aesthetic improvment in their code has nobody to blame but themself if and when it happens.

That IMO is laughable, in a compiled langauge you may on occasion redesign a command or structure, then well docuement the alteration, any code that now needs to be recompiled under the new version, may need fixing.
On the other hand the idea of a overall structure change such as the way it handles spaces, in a non compiled but interpreted language, would be foolhardy at the lightest.

On simply using multiple spaces for cosmetics of display of the code, well that was a hand written example, I have had to write plenty of lines that have half dozen levels of function imbedding, you need to rely on facts like using spaces either single or multiple well not cause problems, the fact that thats one of the princables of white spaces in code might have been forgotten in the arguement here. as an example ill give you this.


results
len1 = 7
< 1 > qwe asd zxc . asd . asd . asd zxc qwe . zxc qwe asd . zxc asd qwe
len2 = 8
< 2 > qwe asd zxc . qwe zxc asd . asd qwe zxc . asd zxc qwe . zxc qwe asd . zxc asd qwe

the above code is a simplified example of say retrieving 3 values from a primary, secondary and tertiary source, and one of the sources may not exist, there order of existence is important, then once retrieved, the combinded value must be located and removed from a list. In the example "qwe" , "" & "zxc" were retrieved forming a need to remove "qwe zxc".
ex1 this is done
ex2 simulates a multiple space altering of the way mirc works, ie "asd" + " " + "" + " " + "zxc" becoming "asd__zxc" (i used __ here as the editor here strips multiple spaces) , this is then removed from the list, which failed as there was no occurance of it.

This is just one example i thought of outa my head.

Well yes, intentionally assigning null values to variables and the like will cause problems. But seeing as old scripts will almost certainly revolve around getting input from $n, which would remain the same in my suggestion, then there would be no problem there.

Assumtions and assumptions

The example intentionally set a null value, to simulate a possable result of a sampling of some other data that resulted in a null value, there was no attempt to show how it would collapse if you delibertly set out to cause it, its not like its hard to cause mirc problems as it is.

I dont really know where you came up with the idea that most old scripts use only $n as input (im assuming u mean $1 $2 etc).

I personally would like to see maybe a alias switch that could be used to define how the interpreter sees spaces.
ex:


this way all current scripts would maintain standard functionality, while allowing for future scripts to take advantage of multiple spaces as needed.

PS: incase someone wanted to comment on that -s idea, i havent really put much thought into that, its a idea, im sure there would be hurdles to overcome with it.

Hi ive heard various ppl bitch and moan that it would be hard to modify the parser to allow for spaces to be left in output etc.

>> from another post..
argv0
The reason he hasn't is most likely that it's a pretty tough problem to solve given the constraints of the parser.

now i also hear u can use binvar's as a get around. now why not have khaled add in something simple where a new identifier to be used in place of $1- ..but as a binvar alternative. so what is passed on is also passed on as a binvar to the next level. or even to output on screen. or even for those who are avbout ot bitch that having everything being passed on ass binvar aswell as the normal way would impact on speed. well there's always adding somethign to the start of the start of a command. such as .msg would make its execution silent to the user. why not have a different letter used as to tell the parser to pass spaces on ad shown in the following line. i dont see how this could be all too hard. so Khaled. lettuce know if its possible. and maybe just fix this whitespace nighmare ....

how about some type of mIRC built-in "tag" or "function" you can put into your scripts that will tell it when and where you want "preformatted text", just like the HTML <PRE></PRE> tags ex:

returns:

This way code from old scripts does not get broken and everybody is happy!