Sivulla https://wiki.gnome.org/Apps/Gedit/FAQ#gedit_is_very_slow_and.2BAC8-or_crashes_when_opening_files_with_very_long_lines._Can_you_fix_it.3F lukee:
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.
Kuitenkin on olemassa paljon editoreja, joille pitkien rivien avaaminen ei tuota ongelmia. Huijaako siis kehittäjät sanomalla cannot be fixed, kun toisaalta esimerkiksi vim tai nano pystyy avaamaan pitkäriviset tiedostot ripeästi?
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.
Kuitenkin on olemassa paljon editoreja, joille pitkien rivien avaaminen ei tuota ongelmia. Huijaako siis kehittäjät sanomalla cannot be fixed, kun toisaalta esimerkiksi vim tai nano pystyy avaamaan pitkäriviset tiedostot ripeästi?
Vastaukset 16
Vanhimmat
"Huijaako siis kehittäjät sanomalla cannot be fixed, kun toisaalta esimerkiksi vim tai nano pystyy avaamaan pitkäriviset tiedostot ripeästi?"
Kyllä sen pystyy korjaamaan. Se vaan ei ole helppoa kun kyseessä on GtkTextView komponentin rajoite, joten joutuisi tekemään kokonaan uuden komponentin ja se sitten työlästä.
Eipä mitään, saat tehdä uuden komponentin vapaasti.
Kuulostaa suurelta työltä. Mitenkähän kannattaisi alkaa selvittämään koodin rakennetta ja opetella C:tä siten, että saisi fixattua bugin? Toistaiseksi olen tehnyt C:llä vain konsoliohjelmia, ja tuollaisten grafiikoiden ja hiirikirjastojen käytöstä ei ole kokemusta
Ymmärtääkseni ongelma on luonteeltaan sellainen, että muu käyttöliittymä ja tekstilaatikkokomponentti pyörivät samassa säikeessä ja tekstilaatikkokomponentissa on joku optimoitu silmukka mikä ei luovuta aikaa muulle ohjelmalle tms. tai se GtkTextView komponentti on tässä tapauksessa vaan viallinen.
Ongelma sitten onkin se, että sitä GtkTextViewiä ei välttämättä voi korjata ilman, että se vaikuttaisi kaikkiin muihin sovelluksiin mitkä käyttää sitä. Pitäis sitten vähintäänkin forkata se erikseen juuri tätä Gedittiä varten tai tehdä uusi komponentti.
Luulisin, että ison koodin ylläpidossa kannattaisi ottaa yhteyttä kehittäjiin. Riittääkö bugin korjaus vai kannattaako koodia refaktoroida helpommin ylläpidettäväksi. Kielimalleilla ei ehkä pysty korjailemaan luotettavasti vielä bugeja, mutta sillä voinee pyytää analyysiä, mitkä voisivat olla projektin pahimmat pullonkaulat ja mihin suuntaan sitä voisi kehittää?
Heh heh.. vastasit sitten yli 10 vuotta vanhaan ketjuun - kannattaa ainakin tarkistaa nykyinen versiohallinta ennen kuin alkaa korjailla vanhaa koodia. Kehittäjätkin ehtineet varmasti vaihtua 2-3 kertaa tuossa ajassa.
Kyllä ne huijaa.
Windowsin notepädissä on samantapainen rajoite. Kokeilepa muokata tiedostoja jossa on yli 1024 merkin mittaisia rivejä.. tuleekin pakotettu rivinvaihto
ei tunne po rajoitteita:
- kwrite ("simppeli teksturi")
- kate ("kehittyneempi teksturi")
Jos GNOMEen ei tunne (?) muita toimivampia tekstureita kuin gedit niin ainahan voi asentaa esmes noita KDE:n tekstureita. Toki vaatii sitten asennus KDE:n lisäpalikoita, jotta toimais myös GNOMEssa...
Näköjään katessakin on joku bugi verrattuna nanoon. Ei avautunut kunnolla kun kokeilin Python-koodin:
file = open("newfile.txt", "w")
text="12"*1000000
file.write(text)
file.close
Mihin niin pitkiä rivejä edes tarvitaan? Ei ohjelman tietystikään pitäisi kaatua mutta jotain häikkää jos rivi ei mahdu kerralla näytölle
Ei niitä kauheasti varmaan tarvita. Tuolla on joku ohjelmointiprojekti, jossa voi tällaista tarvita: http://www.ohjelmointiputka.net/posti.php?tunnus=mpera . Mutta ilmeisesti tällaisia varten editorit tulisi tehdä siten, että alussa ei avata koko tiedostoa vaan alkupätkä ja rivejä ei lueta kokonaan vaan joku tietty osa, ja kursorin liikkuessa osan yli luetaan taas uusi pätkä. No, en ole ohjelmoija, en tiedä miten he tekevät asian omissa ohjelmissaan.
Kun liikutaan äärirajoilla niin siinä missä GUI-sovellus jämähtää niin vastaava CLI-sovellus toimaa. Johtunee siitä, että jälkimmäiset vaatii huomattavasti vähemmän laiteresursseja.
Yhtä hyvin voi kokeilla esim. libreOfficella, mitä tapahtuu, kun tiedostossa on puoli miljoonaa 3 merkin mittaista riviä: Tiedoston avaaminen kestää ja editointi ei välttämättä onnistu - tyylin vaihto fontille voi kestää useita minuutteja. Samaan aikaan Emacs avaa em. tiedoston sekunnissa. Samaisen libren taulukkolaskennan import-toiminto muuten voi kaatua tuohon rivimäärään, jos koneessa ei ole tarpeeksi muistia.
Palautehan on ihan asiallinen!
"gedit on erittäin hidas ja/tai kaatuu avattaessa tiedostoja, joissa on erittäin pitkiä rivejä. Voitko korjata sen?
Suunnitellessaan GtkTextView:n (gtk:n tekstinäyttöwidgetti, jota gedit käyttää) kehittäjien oli tehtävä suunnittelupäätös: heikon suorituskyvyn ja muistin käytön vaihtaminen nurkkakoteloihin, kuten erittäin pitkiin riviin, vastineeksi paremmasta suorituskyvystä hakutoiminnoissa ja täydellisestä UTF-8-tekstin tuesta. Tämä on GtkTextView:n tunnettu rajoitus, eikä sitä voida korjata."
Jos geditillä pystyy n. sivun mittaisen tekstin kirjoittamaan niin sehän toimii riittävästi! Pidemmät tekstit voi kirjoittaa jollain muulla n. 2000 tekstinkäsittelyohjelmasta, mitä maailmalta löytyy. On kirjoittajan ongelma, jos hän hukkaa tekstiä tekemällä järjettömiä.
Kyseenalainen aloitus, koska kyse on teknisestä esteestä em. ohjelman kehittäjillä - omaa ohjelmaansa ei ole pakko jatkoehittää - sen saa jopa rikkoa halutessaan. Ei ole siis kyse huijaamisesta - vaan aloittajan kateudesta tai omasta osaamattomuudesta: Lähdekoodit kun on saatavilla ja aloittaja voi halutessaan tehdä tarvittavat muutokset ja samalla todeta työn olevan suuritöinen.