Stefan Schimanski wrote:
Am 25.02.2008 um 15:10 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 25.02.2008 um 14:45 schrieb Abdelrazak Younes:
The math completion works but not the text, is that normal?
Well, depends on what you call working. First I disabled the
automatic completion for text because it might be annoying for many
people.\
What is the purpose of the "Automatically show in text mode" then?
If you select this, it will be shown. But by default, the checkbox is
not selected.
OK.
So you have to press tab after entering the first character of a word.
It doesn't seem to work: I hit tab and I get nothing.
So it does not work. I guess it's connected to the bug you had before.
Quite possibly yes.
You are using Linux?
No, Windoze...
Second the data collection is very poor because I wanted to get the
backend, WordList, working first in a proper way. So it only adds
words when closing them with a space. I.e. type lalalala<space> and
the word is added to the WordList.
The next step is to fill this word list in a better way. One idea is
to take the longer words from the document.
Yes, at initial file parsing would be good.
Adding words to the word list as it is not, in addition to initial file
parsing, is also a good idea IMO. But I am not sure how one could handle
deletion of words. I mean imagine you make a spelling error in a new
word. It is added to the list. Then you realise the mistake and you
correct it. Should the wrong word stay in the completion?
Hum maybe we should also count the number of occurrence of a given word
and offer it as a completion choice only it was used alt least 2 or 3
times. This would lower a bit the probably to reuse a word containing a
typo.
> That would be
confusing IMO. One could add some kind of reference counting to words
and erase them as soon as the counter goes to zero. Not sure though how
complicated this is.
You mean a "clear" button next to each completion word? That would be a
bit complicated. A dialog to add and clear the completion list on the
other hand...
Another would be to use a dictionary word list.
Would be nice too.
Indeed. And it is quite easy to implement.
Btw, one thing I wanted to mention to you: using the weighted_btree one
could get rid of the loop in the scrolling code which adds the heights
of paragraphs. You have to use the height (or some guessed value of
those without known metrics) as the weight in the weighted_btree. Then
the summing up is logarithmic in the paragraph number, not linear as it
is now. You can even update the weight (i.e. height) of a paragraph in
logarithmic time (I have to add an update_weight method to the
weighted_btree. But it's easy). There is never the need to go through
all paragraphs then.
No idea if this gives a noticeable speedup for the scrolling. For very
long documents I am quite sure it would. Do you have any numbers how
long this takes e.g. for the user manual?
The loop based approach is very fast here (i.e. not noticeable). It is
in any cast much faster than an actual screen drawing so, unless there
is a code simplification, I won't bother for this optimisation.
Abdel.
