Dotaz: Proklatě líný Kate

[xkesh]

Občas se pokouším používat editor Kate (KDE) i pro psaní obyčejných textů. Dokud píšu plynule na konci textu, vše běží normálně svižně.

Když začnu ale doplňovat slova nebo věty do již napsaného textu, tj. někam doprostřed, Kate se neuvěřitelně zpomalí, tj. grafické zobrazení písmen následuje stisky kláves až s velkým zpožděním, které prakticky znemožňuje normální psaní.

Tuším, že by to mohlo být způsobeno tím, že se celý text prohledává kvůli zvýrazňování kódu (mám zapnutou wiki-syntax, občas html-syntax), ale popravdě řečeno, nepřipadá mi to "fér", a proto doufám, že tím to nebude...

Máte někdo podobné zkušenosti s Kate nebo vůbec s psaním normálního textu v tomto "pokročilém textovém editoru"?

Čím by mohlo být tohle chování způsobeno a dá se nějak opravit?

Je možné, aby byl tento editor o tolik línější a k psaní běžných textů nepoužitelnější než tak proklínaný Openoffice.org Writer?

(provozuji KDE 3.4.1 v Gentoo, verze Kate je 2.4.1)

Odpovědi

[pard]

možná hloupý dotaz, ale zkoušel jste to bez zvýrazňování?
kde, kate mám ve stejné verzi jako vy, také na gentoo a i při syntaxi nezaznamenávám zpomalení, zapnuté mám i doplňování slov a aspell

[xkesh]

možná hloupý dotaz, ale zkoušel jste to bez zvýrazňování?kde, kate mám ve stejné verzi jako vy, také na gentoo a i při syntaxi nezaznamenávám zpomalení, zapnuté mám i doplňování slov a aspell

Zkoušel, a nic. Proto si taky myslím, že to tím nebude, ale zatím marně pátrám, čím by to být mohlo.

Totéž se mi děje i když se přepnu do jiného uživatele, a kupodivu i editoru KWrite takže to může být nějaká volba KDE, nějaká zasekaná cesta? Kde bych měl asi tak začít hledat?

Pro upřesnění ještě dodám, že se jedná o texty (nikoliv konfigurační soubory), které mají tak 50 odstavců (v Kate řádek) a že píšu všemi deseti. Kódování používám UTF-8 jako výchozí, i když ho občas měním.

Pokud bych datloval v kratším textu, tak je zpomalení zobrazování samozřejmě zanedbatelné. Ale takhle napíšu i dvě slova dopředu dříve, než se vypíšou na obrazovku - a rozhodně nejsem žádný přeborník v rychlosti.

Jinak jsem s odezvou programů v KDE 3.4 Gentoo spokojenej, až na ty dva editory :(

[Michal Kubeček]

které mají tak 50 odstavců (v Kate řádek)

Tomuto nerozumím. Odstavec je přeci něco úplně jiného než řádek.

[xkesh]

které mají tak 50 odstavců (v Kate řádek) Tomuto nerozumím. Odstavec je přeci něco úplně jiného než řádek.

Dobra, tak tedy oddilu textu oddelenych odentrovanim (coz Kate chape jako konec radku, aspon podle cislovani radku).

Ze by byl problem v tomto? Moc dlouhe "radky" (= odstavce)? Je tedy Kate & spol. nevhodny nastroj pro psani TEXTU?

[Michal Kubeček]

Kate je textový editor, tj. nástroj pro editaci textových souborů. Není zamýšlen jako textový procesor, tj. nástroj pro formátování textu. To, že příliš dlouhé řádky na obrazovce rozláme tak, že to budí dojem jakéhosi jednoduchého zformátování, je jen způsob, jakým se vypořádává s kilometrovými řádky, ne normální způsob používání tohoto editoru. Chcete-li formátovat text, asi bude vhodnější použít OOo Writer, který je k tomu určen.

Na druhou stranu, zkusil jsem nasimulovat vaši situaci a běžné psaní doprostřed textu se mi nijak nezpomalilo (SuSE 9.3, kate 2.4, KDE 3.4.0b). Narazil jsem ale na trochu jiný problém: i u běžných textových souborů (konfigurační soubory, programy…) mi kate neuvěřitelně pomalu scrolluje, pokud jsem na "druhé stránce", tj. na řádku mezi n a 2n, kde n je počet řádků, které se vejdou na obrazovku…

[xkesh]

Chcete-li formátovat text, asi bude vhodnější použít OOo Writer, který je k tomu určen.

K pouhemu psani jednoduse formatovanych textu (tj. prakticky jen odstavce) mi prave OooWriter s temi kancelarskymi a formatovacimi funkcemi prijde jako dost tezka vaha...

Stejne tak KWord a Abiword (kterym navic chybi pohodlny nahled na zvetseny text bez ohledu na layout, v OOo web-layout, v MS Word Normal view).

Existuje tedy nejaky JEDNODUCHY a rychly textovy "procesor", kde lze psat svizne i delsi texty?

V zasade nepotrebuju extra funkce... i kdyz se mi velice hodi obcas zvyraznovani html syntaxe, kdyz napsany text formatuji pro html, tak jako je to v KWrite a Kate a hodilo by se, kdyby umel ukladat (a prevadet) Unicode.

[Roman Plášil]

Já bych doporučil třeba Vim.. Teď jsem to schválně zkoušel, editovat 15 MB soubor vč. syntax highlight a naprosto v pohodě, akorát ukládání trvalo jako by to zapisovalo 15 MB textu :)

Možná bude ale trochu problém s ovládáním, protože je značně netradiční, ale integrovaný tutorial by Vás měl nakopnout.

[wake]

no uz to vidim...

HandlerResult EditorWidget::KeyboardHandler(const EW_X_KEY &key)
{
  .
  .
  case EW_X_KEY_INSERTABLE:
    if(! this->currentLine )
      this->currentLine = new EditorLine(this);
    this->currentLine->insertChar(this->currentLine->getCurrentPos(), key);
    break
  .
  .
  .
}

.
.
.
void EditorLine::insertChar(EW_L_POS pos, EW_X_KEY &key)
{
  if(! this->string )
    this->string = new EString(evtKey);
  else
    this->string->assign( this->string->subString(pos) + String(key) + this->string->subString(-pos) );
}
.
.
.

//

[Kyosuke]

Hmmm, to bude to nové eXtrémní Programování™...

[Kníže Ignor]

Tak určitě by se dala vymyslet chytřejší datová struktura pro uložení řetězce, která by počítala s tím, že se dovnitř budou přidávat znaky, a při nárůstu složitosti by se konsolidovala do nějaké jednoduché podoby, ale to by s touhle strukturou musel umět pracovat i vykreslovač textu, ne? Nedovedu si představit jak to řešit jinak, když mám vykreslovací proceduru, která bere jenom stringy...

[Kyosuke]

Mno, že by GoF a deque s ukazatelem muších vah nebo tak něco?

[Kníže Ignor]

GoF je goodness of fit? O zbytku věty nemám páru...

pokud bych to já dělal, tak bych měl pro řetězec alokováno víc paměti - nějaký prázdný místo na začátku, pak ten řetězec, zbytek volného místa; ukazatel na začátek řetězce

při přidávání znaků dovnitř řetězce bych posouval vždy kratší část doleva nebo doprava, pokud by to šlo, jinak bych alokoval novou paměť a doprostřed nakopíroval řetězec

tohle bych uměl dělat v céčku, ale jak fungují stringy v C++ netuším

[sf]

No ja nevim, ale kate pouzivam na psani zdrojaku a zadny zpomaleni nezaznamenavam.

[Marián Oravec]

doggy@wetnet:~$ free
             total       used       free     shared    buffers     cached
Mem:        767544     501248     266296          0      15684     302900
-/+ buffers/cache:     182664     584880
Swap:       491360     193888     297472


doggy@wetnet:~$ ls -lh Doc1.csv
-rw-r--r-- 1 doggy doggy 56M 2006-06-16 09:56 Doc1.csv

doggy@wetnet:~$ wc -l Doc1.csv
124262 Doc1.csv


doggy@wetnet:~$ kate Doc1.csv

So zapnutým "KTextEditor Word Completion Plugin" je Kate (2.5.3) nepoužiteľné. Po jeho vypnutí nepozorujem ani s týmto 56 MB súborom *žiadne* spomalenie. Nebude to u Vás spôsobené nedostatkom RAM?

[tommz]

Spíše bych to tipnul na grafiku.

Když píšete normálně na konec textu, tak se vždy dokreslí jen jeden znak. Ale když dopisujete do textu, musí posunout třeba několik set znaků .... možná by pomohlo vypnout vyhlazování znaků v KDE a takové další serepetičky.

[Robert Krátký]

K tomu se připojuji. Kate/KWrite se mi výrazně zrychlil ve chvíli, kdy jsem v nich začal používat bitmapové fonty. Sice se mi nikdy předtím nestalo, že by nestíhal tolik, jak popisuje xkesh, ale přesto jsem se tím zbavil nepříjemného trhání.

[Marián Oravec]

Ja používam DejaVu Sans Mono (ttf-dejavu). Mal by sa vyjadriť xkesh, či to nie je naozaj nedostatkom RAM.

[misterlister]

Myslím, že xkesh to jistě již za ten necelý rok vyřešil

[David Watzke]

Právě, že nevyřešil, proto se otevřelo tohle starý vlákno...

[Kyosuke]

To je zajímavá úvaha, kde přesně ho vidíš takto činit?

[David Watzke]

xkesh na tuto diskusi odkazoval zrovna včera.

[Kyosuke]

A sakra. To je skleróza. Přes tenhle link jsem se sem vlastně dostal...

No, některý mušky přežívaj dlouho, tak asi i tahle. Jestli bude dost zájmu, tak to nakonec opravěj, pokud nebude...no, moc lidem to vadit nebude...

[David Watzke]

V KDE changelogu 3.5.3 > 3.5.4 se píše:

Fixed slow repaints of dynamically wrapped lines. Fixes bug 128690. See SVN commit 549739. See SVN commit 549908. See SVN commit 550220.