Re: gedit bug with long lines. (was RE: gedit slow with a 1.5Mb text file)
On Monday 02 February 2015 03:02:38 Curt did opine And Gene did reply: 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. One thing I would like to have seen was a definition of what they called a long line. Where I was having trouble, and had to abandon its use, was in an approximately 400 line file, with line lengths of perhaps 140 chars worth of 7 bit ASCII text per line maximum. Is that a long line? I had it play mix-n-match with the order of the text, or mix old text with new, growing the file by 2 or 3 hundred lines of gibberish, totally demolishing a .hal configuration file controlling a CNC lathe or a milling machine, both with power enough to kill if it miss-behaved. I have a philosophy about such things, and I will fix a problem like that for good when it happens for the 3rd time. In my case, the fix was geany, which has not added or dropped a character my ancient (80 yo) arthritic fingers didn't miss-type. Gedit has more language highlighting plugins than geany, in particular one for RS-274 GCode, that geany doesn't have, but I lack the skills to write that, nor is its plugin interface well described in the docs I have found. But it does Just Work(TM). Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS -- 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/201502020448.42384.ghesk...@wdtv.com
Re: gedit bug with long lines. (was RE: gedit slow with a 1.5Mb text file)
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
RE: gedit bug with long lines. (was RE: gedit slow with a 1.5Mb text file)
Curt wrote: 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 I was searching for bug reports; I hadn't expected an FAQ to exist on the very topic I was interested in. Quite honestly that's a first. FAQs as I tend to encounter them never have anything useful. I'm actually quite impressed. Thanks for the link. 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 Long lines are a corner case? 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. This is what I had gleaned from the various bug reports; the issues is known but for some reason it's really hard to fix. 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. So I guess this isn't getting fixed anytime soon. Cheers. -- 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/001801d03ec9$e77c0e40$b6742ac0$@ozemail.com.au
