Forums Feature Suggestions /clear and other addition (del a line of text)

Just a thought I was having the other day...

It would be rather neat if /clear had the ability to do what /dline does for custom windows, and perhaps even to have /dline have the ability to delete a range of text lines from a channel window.

For instance, if one was to use /clear -d 1-4 #channel, it would delete lines 1-4 from the window buffer, and the window itself.

Then, I thought of something else, why not make it so that all the xLINE commands (such as /aline, /dline, /cline, /iline, etc) could manipulate the text within a channel window.

This would be handy for cases where you want to sort the display of certain channel statistics, for instance, if you wanted all the channel modes, urls, topics (all the channel related stuff you get when you join a channel) to be sorted and presented in a tidy manner.

For instance:

[13:56] ** Now talking in #channel
[13:56] ** #channel topic: "blah blah blah blah bleh"
[13:57] ** #channel modes: +pntl 50
[13:57] <nick1> hey hey!
[13:57] ** #channel url: www.gohome.com

would be able to be re-arranged to look like this:

[13:56] ** Now talking in #channel
[13:56] ** #channel topic: "blah blah blah blah bleh"
[13:57] ** #channel modes: +pntl 50
[13:57] ** #channel url: www.gohome.com
[13:57] <nick1> hey hey!



There are many other uses, such as having a script that automatically strips all the text of people that you have added to your ignore list from the channel window (but not the logs!), or for using with /fline to apply changes to certain text so you can "highlight" your found entries with a different colour from normal text...

Anyway, this is just a though and an idea.

Agreed.

I've asked in numerous posts for /*line commands to be allowed to work in channel windows and nicklist boxes... leave it to the user to worry about IAL sync issues from /rlineing a nick, etc. I never understood why we're not allowed to /rline from the channel buffer though.

- Raccoon

i would say it was decided that manipulating the channel window, could to easly lead to manipulating the gulable person looking at it, a rouge script could alter the contents of a channel to appear to be something else etc etc.

(comment below is in general not aimed at you)
I think its a bit arogant to believe that everyone can disect a script and what it does, so if a script appears to be ok, alot of people well use it, just that some code hidden in the middle does soemthing else.

Anyway...
A channel window can always be filtered out to a custom window then edited at will, i cant see it being all that hard to make it appear just like a real channel, with the real channel being a hidden window.

*nods*

My only problem with that reasoning is that there are so many other commands that shouldn't exist if we are to worry about the infection of gullible users. Making channels out of custom windows is a HUGE undertaking, and one that breaks all simple/conventional scripting methods... its simply not worth it.

At present, you can silently .ignore people and a gullible user would never know unless they looked. You can even /halt the TEXT event to prevent said line(s) from being displayed, something that is less difficult than going about it with $fline and /rline.

I understand where you're coming from, but I feel my scripting enjoyment shouldn't be unreasonably hampered by some remotely foreseen gullible user. This is my stance with On KeyDown/Up in channel windows, too. (Note: Khaled had set /window -h NOT to hide the channel switchbar tab in one version, for a similar fear of trickery. I was equally vocal against this move too.)

- Raccoon

i re read my message , and i did sound against the idea, which isnt actually my stance, i would like to be able to manipulate everything personally, I just ment i think thats why it was/is done that way.

I would like to be able to have really no borders at all, you can end up needing all types of odd things doing legit coding, I remember once, asking a guy who wrote the teknap program (a unix based text only, free napster server client) to add a command to FAKE any event at all, basicly becuase i was having trouble testing event traps and also wanting to trip some events based on this or that (i cant remeber why tho)

I must admit this client is far far larger used of course, but for testing it would be a nice command, maybe a command that has to be acknoledged when first run no predefined settings, since you wouldnt use it often, besides testing etc,
Currently on most events, im stuck doing this.
on *:text:*:#:/eventaliasname $nick $chan $whateverelse $1-
then i can test the routine by calling it manually with values past.
(i have gone right off topic lol)

You probably know that you don't need to pass $nick/$chan on to the alias, you could also use $rawmsg in the alias.

• on *:text:*:#:/eventaliasname
  alias eventaliasname echo -a $nick - $chan -- $rawmsg

personally, i just parse in incoming with an on *:text: and halt. it works fine, and if you need to parse more, write it to a temp.txt file, parse it, then echo it.

Well, I wouldn't be writing to file to parse it, but whatever turns you on I guess...

And that achieves nothing but a lot of disk accessing. Its great as an interim solution, but long term, its pretty dodgy...