Bug de som semelhante?
Não tenho certeza se esse problema está relacionado ou não, mas se você observar os detalhes desse problema no rastreador de problemas do Bluefish bugzilla. O problema é intitulado: Linhas muito longas e uso de cpu , que não soam relacionados, mas se você olhar através da pergunta:
trecho
I've tested this with bluefish 2.2.2, built against gtk+-2.24.17 and later against gtk+-3.4.4, I got the same behavior.
I do a lot of css editing, and I found some time ago that base64 images where a problem. And the bigger they were, the bigger the problem was as well.
base64 images can result in very long lines, even small images, because bitmap info has to be stored using a subset of ascii (or whatever). So it's not strange that I end with lines with +10,000 columns, sometimes much longer.
When I scroll down such a file, the very moment the offending line is about to appear the editor freezes, and I can see gkrellm becoming mad about cpu usage. I can open the same file in nano and scroll as I wish without even noticing a cpu peak.
When a CSS file is full of this stuff I just close bluefish and use whatever is at hand instead.
Um dos desenvolvedores fez este comentário:
thanks for reporting, unfortunately this is a known bug in the gtk textview widget.
there is a bugreport for gtk somewhere in bugzilla, but it hasn't been fixed for years. I'm surprised that the windows build doesn't have this problem, it also uses gtk....
Eu percebo que o erro que você está vendo parece diferente, mas esses dois problemas parecem ligados a mim. Eu sugeriria arquivar isso como um bug e ver o que os desenvolvedores
Problema aberto em relação a isso
Para tentar ajudar a agilizar esse problema para você e para o outro OP na AU, arquivei isso como um bug no Bugzilla para o projeto Bluefish.
Sinta-se à vontade para comentar sobre isso, esperamos ouvir algo em breve sobre esse assunto.