I solved this bug. I do not know if my workaround create other issues, but it works properly so far.
The problem is about the way 'ord()' deals with special characters in the final 'while' of
/usr/lib/gedit/plugins/joinlines.py
It seems to be a known issue in python.
You can try it out in python:
>>> char='è'
>>> ord(char)
fails, while
>>> char=u'è'
>>> ord(char)
works.
I did not managed to rewrite a working definition of 'char' in joinlines.py, but I believe that the call 'ord(char)' is only a test for 'while' to check is a character is found. Therefore, if a "string of length" >1 is given as 'char', in this case, it does not matter what character is, but only that 'char' contains a character.
As a newby of python, I solved this bug for the split/join-lines plugin replacing the two calls 'while ord(char)' with
'while ord(char[:1])' in the final lines of the file /usr/lib/gedit/plugins/joinlines.py,
it works!
I solved this bug. I do not know if my workaround create other issues, but it works properly so far.
The problem is about the way 'ord()' deals with special characters in the final 'while' of gedit/plugins/ joinlines. py
/usr/lib/
It seems to be a known issue in python.
You can try it out in python:
>>> char='è'
>>> ord(char)
fails, while
>>> char=u'è'
>>> ord(char)
works.
I did not managed to rewrite a working definition of 'char' in joinlines.py, but I believe that the call 'ord(char)' is only a test for 'while' to check is a character is found. Therefore, if a "string of length" >1 is given as 'char', in this case, it does not matter what character is, but only that 'char' contains a character.
As a newby of python, I solved this bug for the split/join-lines plugin replacing the two calls 'while ord(char)' with gedit/plugins/ joinlines. py,
'while ord(char[:1])' in the final lines of the file /usr/lib/
it works!