You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
I think there would be merits to providing a "spell check status" service to spell-check. This would let additional packages listen to the results of the checking status and use it to display information separately or to hook up into additional services, such as linter.
This would defined a new service for spell check such as spell-check-reporter?
When the spell-checking is done for a specific buffer, it would call a method to each of the reporters with the results. Those packages would then render or update the views as appropriate. There could also be methods to indicate when checking begins in the background Task.
At this point, the method signatures or data isn't really defined. I would expect it would be sufficient to give a total number of misspellings (#136 and #97) and also tie into the linter system for those who use that (#80).
In #120, the internal checkers were implemented as part of that package. The same could be done here with the current highlighter (along with Control-: logic) implemented as a dedicated reporter. That way, there is a simple path of logic for handling reporting instead of custom logic for built-in and non-built-in (plus the disabling logic).
Those dedicated reporters could then be broken out into separate packages so they can be disabled if a user wants to use the linter version instead.
I think there would be merits to providing a "spell check status" service to
spell-check
. This would let additional packages listen to the results of the checking status and use it to display information separately or to hook up into additional services, such aslinter
.This would defined a new service for spell check such as
spell-check-reporter
?When the spell-checking is done for a specific buffer, it would call a method to each of the reporters with the results. Those packages would then render or update the views as appropriate. There could also be methods to indicate when checking begins in the background Task.
At this point, the method signatures or data isn't really defined. I would expect it would be sufficient to give a total number of misspellings (#136 and #97) and also tie into the
linter
system for those who use that (#80).In #120, the internal checkers were implemented as part of that package. The same could be done here with the current highlighter (along with Control-: logic) implemented as a dedicated reporter. That way, there is a simple path of logic for handling reporting instead of custom logic for built-in and non-built-in (plus the disabling logic).
Those dedicated reporters could then be broken out into separate packages so they can be disabled if a user wants to use the
linter
version instead.cc: @as-cii
The text was updated successfully, but these errors were encountered: