Hi Matthew,
> Daniel wrote: >> > http://soc-grammar.blogspot.com >> >> > 6-) (Thomas Lange) The checking should stop in the first error found. >> >> For checkers that do real parsing that makes sense, less so for checkers >> that scan for word/part-of-speech sequences. > > I agree. The check should not stop at the first error found. I don't > think this is within the scope of the API -- this should just call > the grammar checkers in turn and handle the results. All of the > grammar checkers should be called, regardless of whether each finds > errors. The grammar checkers themselves might wish to stop at the > first error and just return that. But the API must handle the case > that other grammar checkers wish to return a list of errors (as > stated in 10). Many of the grammar 'errors' will actually be > recommendations, and the user may rightly choose to ignore them. We > can't let errors hide one another. Well I would still like to go with stopping at the first error because they reasoning from last year seemed to be plausible. Also it keeps things simple and that is always good. But I won't make any decision about this because I'm not the specialist for these things. That topic should best be sorted out by people who know about grammar and have actually implemented a grammar checker, because one has to keep in mind that things have to be implemented somehow and if that can not be done properly it'll be a waste. I just hope that in the end anyone will agree that what was chosen is the best way to do things... Thus I'm just throwing in that there are at least two ways to dot this: - have a single API call retrieve all errors from a single grammar checker for example as a sequence of structures each of them giving the relevant information about a single error. or - having a sequence of calls each one retrieving only one error at the time. Of course for this the API call must provide information about where the last reported one was found to start looking from there and return where the next one is found. This way should be possible to properly iterate over the text. I have not thought about yet if any of these approaches has a substantial advantage over the other. > However, we do need to work out how to manage the case where two > errors overlap (we need to make it obvious to the user that there is > more than one error there). One approach would be to change the right- > click menu so that it displays at the top level the different > sentence parts with errors, and under these the options for change. > For example, consider the following: > > An broken sentence. > ~~~~~~~~~~~~~~~~~~~ > [whole thing wavy underlined because one of the errors spans the > sentence] > > Right-click menu could have the following structure: > An broken sentence. > "Fragment" > No suggestions > Show detailed description > An > "Use 'a' not 'an' before a consonant sound." > Change to A > Show detailed description > > Where "An broken sentence" and "An" are at the top level of the menu. To me this sounds somewhat like the fabulous "all-in-one device for every purpose". Sorry. ^^° Is this really necessary? I would expect the users who use automatic checking will use this also because they are capable of correcting the sentence readily when seeing that it is wrong. Likely they are only going to resolve spelling errors by means of the context menu. At the very least I strongly believe a detailed description should never be part of a context menu. And that each entry should have only a single line. Thus if you like to have more details you should invoke interactive checking. However I see the reasoning to provide a short explanation when there is no suggestion. Thus in the above case I like to suggest that the context menu should display sth. like this if the whole sentence is to be marked as wrong: [Fragmented sentence] ---------------------- A broken sentence Where the text above the line is the short explanation and can't be selected and the text below the line should always be a replacement for the whole(!) of the selected text. Maybe we could add some character/hint that choosing the replacement will not actually solve all errors. Or maybe at most all short explanation should be listed above the line: [Fragmented sentence] ['a' used before consonant] ---------------------- A broken sentence And those entries should really be short in length because the get used in a menu! Anyone looking for a longer explanation should use interactive checking now. BTW: Monday is a local holiday here thus I will be back on Tuesday. See ya, and have a nice weekend! Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
