Irssi core bugs

This bug effectively prevents me from using version 0.8.12. Meanwhile, version 0.8.11 works just fine.

Disable recoding of channel names. Recoding of nicks is still on, might cause The Suck to emerge. /eval j tko-\xe4ly works though :)

This only affects you if the channel name has a different charset than the terminal. Ie. if the terminal is latin1, test\xE4 works but test\xC3\xA4 is broken. Vice versa when using a utf8 terminal.

After applying the patch, there are no longer two separate windows for each such channel and I suppose the basic messages go to the right window, but many other things remain broken. For example, "/names" in the channel window shows an empty list and the names list on join goes to the active window (instead of the channel window where it belongs).

Can you try with irssi svn ?

Can you point me to compilation instructions for the svn version? ./configure fails with "configure: error: cannot find install-sh or install.sh in build-aux "."/build-aux"

nikanj: run ./autogen.sh

ayin: tried, with svn checked out this morning. I see no change in behaviour whatsoever, channels still break as described above.

Supposing the channel is on server with tag 'foo' and its encoding is 'ISO-8859-1', it should work if you add a recode conversion for the server with '/recode add foo ISO-8859-1' or if you set recode_out_default_charset and recode_fallback to ISO-8859-1.

Ok, with those recode settings it works somehow - channel opens correctly, but it also opens one useless empty window. Closing that empty window parts you from the channel also.

Another thing - with iso8859-15 it doesn't work. Haven't checked the source, but this sounds like some clumsy workaround. There are other charsets than just iso8859-1 and utf-8.

And you are wrong, it is not some workaround limited to iso8859-1.
The code currently performs a conversion, for both incoming/outgoing messages, on the full message.
I'll try to reproduce the problems.

Ok, that is good to hear.

It would be nice though to give warning or to have a workaround for users accustomed to using /eval join (and who have added channels to config file with /eval channel add), instead of just breaking up.

I did the following test:

client 1 (term_charset ISO-8859-15)
/join #test\366

client 2 (term_charset UTF-8)
/recode add foo ISO-8859-15
/join #test\303\266

It works fine, and creates no additional windows.

Ah, true. I didn't realize that there is no need for the /eval trick anymore, simple /join #testö is enough.

I wonder though how it should work if I have both utf-8 and latin1-named channels on the same server. Not as important for me, but during transitional period to utf-8 I think this is going to be quite common.

Yes, that is a limitation which can be solved by

- associating an encoding to the channel
- converting the line selectively so that the channel name is converted using the associated encoding and the rest of the line using a server/channel preference for text encoding.

Other than the work involved, this adds quite a bit of overhead to message processing and i'm not sure it is worth. All the irc clients that i know support only a server encoding preference with which the whole line is converted.

Note that you can also specify a recode preference for a channel, but it does not play well if the channel includes 8bit bytes because the name would be stored in your encoding. An alternative could be to allow /recode to accept hex escapes so you could do /recode add #test\366 ISO-8859-15. This of course would mean that the whole line is converted with the channel name encoding, but i think the aproximation 'channel name encoding == text encoding in the channel' should work in most cases.

What do you think?

I think that the mixed-encodings problem is not worth too much effort, but having a known work-around would be good. Atleast having two server connections with different encodings should work, but this will mean different nicks on channels.

Currently there is also trouble when recode settings are changed on the fly. Would it be possible to store the actual byte-string used for channel name when transmitted to server somewhere along with the displayed channel name, and use it for all server communications (and compare to it when receiving messages)? This way, recoding would be done only on join, and it might be possible to also have something like /join -charset UTF-8 #testö or /join UTF-8/#testö.

If all channel name recoding is done in one place, a prefix like UTF-8/ would allow using it for any command (/channel add, /part, etc.). The displayed name could have the associated prefix if it was given on /join, thus solving the problem of having both UTF-8/#testö and ISO8859-15/#testö open at the same time.

Are there instructions for overcoming this? I tried the solutions suggested here (/recode add.., recode_out_default_charset and recode_fallback), but still got 2 windows or wrong channel. Patching and/or installing irssi versions is not in my power and no UTF is a downer. What broke it anyway...

I reverted recode to pre 0.8.12 behaviour, for any update regarding 8bit channel names see bug #432.