On 2015-02-02, Wayne Hartell <w.hart...@ozemail.com.au> wrote: > > In case anyone is interested, I did some further research into this knowing > the issue is long lines and it seems that the bug has existed (and been > known about) for many years, but still not fixed. The earliest bug record I > can find dates back to 2003, so I'm guessing the work around is my best bet > for the foreseeable future. :) Either that or address the "problem" on the > source side. >
The *gedit faq* is edifying on the long lines issue (seems like you missed reading it in your "research): https://wiki.gnome.org/Apps/Gedit/FAQ gedit is very slow and/or crashes when opening files with very long lines. Can you fix it? When designing GtkTextView (the text display widget of gtk+ which gedit uses) the developers had to make a design decision: trading off bad performance and memory use on corner cases like very long lines in exchange for better performance in search operations and full support for UTF-8 text. This is a known limitation of GtkTextView and cannot be fixed. On top of that Pango seems to use a lot of CPU drawing such long lines. This may be fixable, but it isn't easy... Feel free to give it a try. Crashes with long lines are usually due to out-of-memory conditions, but if that's not the case then we would like to know about it. -- “There’s no money in poetry, but then there’s no poetry in money, either.” —Robert Graves -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnmcubou.1ve.cu...@einstein.electron.org
