Forums Bug Reports echo -i bug

Hi,
I've either found a bug or an undocumented feature in echo's i parameter.
Apparently the indent is limited to 25 characters, so it would not make a difference whether you specify 25 or 50.

A demonstration:


I believe this is a bug, as setting a limit to me seems useless. However, if it is not a bug, it should be mentioned in the mIRC Help.

Anyway, this currently leaves me with a problem, as I need it indented with 29 characters. Does anybody have a temporarily solution?

I'm using mIRC v6.21

I would think that this is a bug, rather than intentional, however, in regards to features that aren't in the help file, there are a few of them, and it would be nice if they were all documented, however, I have no idea if the size of the help file might be a contributing factor to leaving them out.

This indent limit has been in effect for a long time, i believe i mentioned it a few times in the past when coming across people looking to script a 'tabular' layout. That, plus the fact that it is certainly not some weird arbitrary number, leads me to believe it was an intentional limit put in place and not a bug.

However, i would also like to see it removed. Maybe there was a reason for the limit when -i was added, though i cant think of why.

I can't see a reason neither, and it totally ruins my layout when I can only indent it with 25.

a temporary solution, might be to check spaces.dll and see if that can be used for the extra 4 spaces, or if you don't want to use an external dll for that, force the 4 spaces using something like
<Ctrl+b><space><Ctrl+b><space><Ctrl+b><space><Ctrl+b><space>

Hmm, bit of painful hack job scripting required to determine where in the line to put the extra spaces heh. And of corse would be hard set so resizing window would mess it up.

Oh, yeah, I agree, but the OP asked for a possible temporary solution, so that's what I gave them.

I already use spaces.dll, but that doesn't help me. I've also asked Saturn (the creator of spaces.dll) if he could fix it, which he said no to.

And I used to use $wrap(), but that's just a pain in the ass. I'd rather be without than not being able to resize my window.

But thanks anyway ;-)

The -i switch was originally added to allow scripters to mimic the indentation that mIRC uses in messages, which is normally 2 spaces, so I assumed that 25 would be more than enough for other uses. I'll extend the maximum in the next version.

First of all, I appreciate that you're going to add it. :-)

I wonder why you say that it is normally 2 spaces. I don't see the use for indenting with just 2 spaces. I'll show you an example of how my mIRC currently looks:



As the red arrows demonstrate, I want to indent the text with additional three characters, so the text will continue exactly beneath the text and not under the nickname.

What he said was that mIRC usually indents 2 spaces and the -i switch was added to allow scripters to mimic mIRC's behavior. He figured 25 spaces would be plenty but is extending the maximum in the next version. You got your request so why are you still arguing your point?

I was not trying to start a senseless discussion, I was just wondering what he meant.

Thanks for straightening it out.

In a default mIRC installation (without any scripts) lines that continue onto the next line (wrap) are indented by 2 characters to make it easier to read. Without any scripts modifying the display, mIRC left-aligns all nicknames in the channel window, so a 2-character indent is sufficient. Obviously, scripts that move the nicknames around will also need to move the wrapped lines around as well.

-genius_at_work