GNOME Bugzilla – Bug 701070
join/split lines plugin not working with multi-byte characters
Last modified: 2020-11-24 10:18:35 UTC
The join/split lines plugin does not work with some UTF8 characters, like Umlauts for example. The console shows a stack trace. The same problem is described in https://bugs.launchpad.net/ubuntu/+source/gedit-plugins/+bug/880267 as I have noticed now. I no longer have the original stack trace, but I remember that the crash happens in "forward_to_word_end" function in /usr/lib/gedit/plugins/joinlines.py. It contains a while loop, and the crash is in the ord() condition of the loop. The same problem probably exists in "forward_to_word_start". I'm using gedit 3.6.2 and the Ubuntu-shipped plugins package, but the problem still exists in git master: https://git.gnome.org/browse/gedit-plugins/tree/plugins/joinlines/joinlines.py I've replaced the while condition with "while not char.isspace()" for "forward_to_word_end" and "while char.isspace()" for "forward_to_word_start". The plugin now works for me. There's another, possibly better, fix in the linked launchpad bug report.
My fix as explained above is a bad idea, because it causes problems with end of file (leading to an infinite loop).
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 seems to be a known issue in python: http://bulgakov.altervista.org/blog/2013/02/20/gedit-joinsplit-bug
Join lines is now implemented in GtkSourceView, by the gtk_source_buffer_join_lines() function. The gedit plugin should be ported to this function, if it isn't already the case.
Mass-closing of all gedit-plugins bugzilla tickets. Special "code" to find again all those gedit-plugins bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.