Le 14 août 07 à 16:22, Helge Hafting a écrit :
Mael Hilléreau wrote:
Le 14 août 07 à 14:01, Helge Hafting a écrit :
What happens if you add a new note?
For that, you will indeed need a document setting saying
"don't spellcheck notes".
Ah! I think we're dealing with some kind of type-level here...
Nothing wrong with that - but the document structure
and screen redrawing should be kept as simple as possible.
A type-level approach would be as much simple (at least): just use
what is already implemented: insets and layouts. The
Inset::allowSpellcheck() method is already there, and what I propose
is just to use it. If you have one note inset now, you'll have one
note inset next; the only difference is that it won't be spellchecked
because its allowSpellcheck() function will return false.
Screen redrawing doesn't need anything more, frame and background are
already visible enough. You'd like a green underline? Then what
happens for already blue underlined text, can we stack those lines?
If no, further coding will be necessary.
Then this is applied at note creation time too.
What about my old document that I created without this option?
Should I "remake" all notes?
It is usually ok that new features only are available after
you get the new LyX. :-)
Ok... but it's better if you can make new features available into new
documents. In fact, this could be possible with a per-character
approach by clicking on a document setting (find all notes into the
doc and mark them as not spellchecked)...
Settings applied at inset creation time keeps
the spellchecker logic (and screen display logic) relatively simple.
Ok, but it makes creation less simple...
Indeed. It is all about "where to put the complexity/slowness".
Screen drawing should be kept fast and simple - it is slow enough
as it is already. At least on some machines. Actually,
put an ERT in a table cell and it is usually slow enough anywhere.
We could just use insets and layouts in a way similar to the way
they're used normally. The special inset wouldn't require much more
processing, even though its display could differ a bit from normal
insets (e.g. lines not broken).
The main window contents gets painted often - not the
place where you want any extra complexity.
I don't understand.
If something extra happens at note creation time, then the delay
will be small because only that one note inset gets a treatment.
If this have to happen at spellcheck time, then we get all these
delays
at the same time. Perhaps this don't matter much for efficiency,
but there is code maintainability too.
But what you propose is to replace one type-level information
(nospellcheck), by two processes (one at creation time, the other at
click on a document setting), the spellchecker test being required in
all cases (however, doing this test on a type base would require less
computations than on a word, or character base). In addition, until
now we just considered notes. What about comments, branches and
layouts ? Degree of abstraction is just too low to deal with all
these things, and maintainability is clearly worse!! I'd prefer to
maintain 1 information, than n processes!
Mael.
