No, Windoze...
Visual C or gcc?
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.
Good idea. At least 2 is a good number I think.
> 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...
No no, I meant some automatic mechanism. If you delete the word from a
paragraph, the reference count should be decreased. The question is
how easy and reliable one can do the counting.
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.
Ok, then it's fine.
Stefan
