I'm writing a script which puts @ in front of nicks when completing them in a twitter channel on bitlbee.
In bug #316 there was a request to make default tab completions in the irssi source stop the 'complete word' signal. This was because the author was printing out debug output, and was surprised when they caught a signal with data filled in by previous functions.
I would consider this a feature, not a bug. I tried using this signal today, having looked at it in signals.txt, and considering the design where an arrayref is passed into the function for you to populate it, I was surprised that it was not coming through populated by the earlier functions that caught this signal - and in fact the signal was being stopped. It didn't seem consistent with the irssi signal design generally.
I think the behaviour introduced in bug 316 isn't useful behaviour because:
Other scripts that catch the signal first might not stop the signal, so you shouldn't write scripts with the idea that "if I catch this signal then it's because nothing else matched" just because the default completion behaves this way. I have at least one other script (tag.pl) which catches this signal early and doesn't stop it so that it goes through to default completions (it actually signal_continues)
If you want to determine if anything has matched before you, there is a very simple way to do this - check the length of @$complist (the first argument to the signal function). There's no need to have the signal stopped to make it possible to do what the original bug filer wanted
Not stopping the signal gives the ability to do several useful things, e.g. add additional completions to the list, filter out unwanted completions, and manipulate existing ones; without having to reimplement the entire default logic in your perl script.
I've searched online for existing scripts that use this signal and might break on this change:
On scripts.irssi.org there is aspell_complete.pl which is dated from before bug 316 and would change behaviour (back to what it was when the author first wrote it) so that if you tab complete e.g. something that matches someone's partial nickname, it will go through the nickname matches first, and then through the aspell suggestion(s). I believe this is better behaviour than currently and likely what the author intended originally
There are a very few scripts which I've found on google but afaict they wouldn't be affected by this change
There is a script by the person who submitted bug 316, only reference I can find of it is on a pastebin several years ago. It actually wouldn't particularly be affected by this bug as far as I can tell. Also I can find no newer versions of this script online or outside this one pastebin, and the version there has a few bugs ( return if $word !~ /([\@\?]).*/; should be return if $word !~ /^([\@\?])/; )
I'm writing a script which puts @ in front of nicks when completing them in a twitter channel on bitlbee.
In bug #316 there was a request to make default tab completions in the irssi source stop the 'complete word' signal. This was because the author was printing out debug output, and was surprised when they caught a signal with data filled in by previous functions.
I would consider this a feature, not a bug. I tried using this signal today, having looked at it in signals.txt, and considering the design where an arrayref is passed into the function for you to populate it, I was surprised that it was not coming through populated by the earlier functions that caught this signal - and in fact the signal was being stopped. It didn't seem consistent with the irssi signal design generally.
I think the behaviour introduced in bug 316 isn't useful behaviour because:
I've searched online for existing scripts that use this signal and might break on this change: