Both /filter and /loadbuf don't know the default colour of a filtered line (the one you specify in an echo/aline command, with no ctrl code), both pass it with the default text colour (or the one you specify, for /loadbuf). I'd like them to match the proper colours by default, or maybe through a new switch.

Examples (assuming colour 3 is green and colour 4 is red):
//window @x | echo 3 @x green | aline 4 @x red | filter -wwc @x @x
- @x won't contain a green line anymore, nor a red one.
//window @x | echo 3 @x green | aline 4 @x red | savebuf @x tmp | loadbuf -r @x tmp | .remove tmp
- Same result.

P.S.: I couldn't find any feature suggestion on this subject, expanding the date range to the maximum etc.

Very nice suggestion, I wanted this forever. Kinda odd that nobody has suggested it so far (including myself), maybe everybody thought somebody else already had :tongue:

This is exactly what I've been thinking about, until I finally searched for it hehe
Indeed it's odd that such a lacking feature that really bugs me wasn't suggested before..

I aggree with the idea would be real nice
I also can see why it doent exist right now, becuase the lines from the source window dont actually contain a color, but were only colored that way in that window, not in the new one. (not that i think that behavour is the best at all, just why it happens)

On the same grounds as you would like to see the color hold when filtered etc, I would like to be able to just sample what it is, as that ability is missing also.
ie:

//window @x | aline $rand(0,15) @x a random color

Now how do i find out what color it was?!?!?!

About finding the colour, I agree. I'd mention that, but the thread just below already suggests that feature.

yeah i saw that after reading this one, but thought oh well.

If it was implemented I think it shoud be with a switch and the default behaviour should remain the same... (backwards compatability).....

As I said, there could be a new switch, although I don't see how this would require backwards compatibility. I mean, just like /echo, /aline etc. indenting switches didn't work well with colours in the past and now they're simply changed, I think the discussed commands could be changed the same way, since I can't see why could one rely on their current behaviour.

In my humble opinion, it could be much more logical if a switch was used to make them treat line colours like they do now, having the suggested behaviour by default.

But again, it'd be fine in any way, as long as the support existed..

While i am normally an heavy supporter of backward compatability, and would say uses a switch to preform a new color passing method, I would really wonder who wouldnt want that happening by defualt, here would be a simple method of pleasing both camps

/filter.properties -fw

now any filters done with out being expcitly set to -ff or -wf or -ww well be -fw, this of course expands out to any switch that might be needed such as -c for transfer color (actual -c in uses so somethings else), this idea could infact be used for all commands.