Cosmetic - olist formatting

[Vizzini]

Hi,

I assume that at some point, someone decided to change the olist output formatting to use 3 columns. The problem is that the use of colour in the short description wasn't taken into account.

E.g

[263004] a necklace of pe [263007] a graduation c [263009] armplates

[263100] (no short descri [263101] a spiked black [263102] a leather cats

[263103] fishnet stocki [263104] knee-high leat [263105] a bondage cuff

[263106] a leather whip [263107] Emma's Silvery [263108] redo

[263109] a Silver Collar [263110] A Blood-red Ve [263111] a Silver Circlet

[263112] A Celtic-K [263113] A Silver Moo [263114] a Silver Bracele

[263115] Leather Slippe [263116] redo [263117] a Thin Silver Ch

[263118] A Sapphire Wan [263119] A Crystal Hear [263120] An Emerald

[263121] a silver velvet [263122] a Bottle of Baca [263123] a silk blanket

[263124] An Emma Pl [263125] a sapphire-stu [263126] a snowflake

[263127] Starfire [263128] a moon wand [263129] a whip of roses

[263130] a rose petal [263131] a wispy rose see [263209] ein schwarze Led

[263210] Syn's RAI[263257] a thin tile shie [263300] A silver penta

The reason for this is that when you're calculating the length of the string (and the padding spaces) you aren't subtracting the number of characters attributable to colour codes. These are of course translated into actual colours later in the routine and so the padding is all screwed up. The other list commands, mlist etc more than likely suffer from the same issue.

Vizz.

[Syn]

<quote author="Vizzini">@Vizzini:

Hi,

I assume that at some point, someone decided to change the olist output formatting to use 3 columns. The problem is that the use of colour in the short description wasn't taken into account.

The reason for this is that when you're calculating the length of the string (and the padding spaces) you aren't subtracting the number of characters attributable to colour codes. These are of course translated into actual colours later in the routine and so the padding is all screwed up. The other list commands, mlist etc more than likely suffer from the same issue.</quote>

Hahah, I have had this on my "to do list" for a while with rather low priority. Now that I know the cause I will fix it ASAP. Or you're welcome to do it if you feel like it, since I haven't set up SVN yet and you've got the active hand in the source for now.

I implented a function a bit back, i believe the name is strlen_no_colors(char *) that gives back the length of the string, not counting the color codes. A simple search and replace should fix the problem for all three editors.

[Syn]

After tearing my hair out trying to fix this so it would do the colors, I just sripped them in all the <x>list functions so at least it aligns for now. 8)</x>

[Nibelung]

Actually, there is a way to do the alignment such that it allows colors…

max = strlen(string) - strlen_nocolor(string) + width;
sprintf(buffer,"%-*.*s",max,max,string);

You take the length of the string, subtract the length of the string sans color codes (this will get the length of just the color codes), add that difference to the normal width.

On the other hand, you could make a strlen_colors(string) that returns the length of all color codes in the string (just returns that difference).

Either way, the * in the %s code means that the width parameter is before the particular argument. In this case, since both are there, both the minimum and maximum widths are just before the string argument.

[Syn]

Hmm, i wasn't aware the printf functions could be used with this syntax. You live, you learn 8)

I was trying to do a ghetto workaround with a second buffer string, and kept running into overflows.

I'll give this a go when I get back home.