Re: wcheck-mode

[Stefan Monnier]

> Either way is fine. The papers have been signed so I guess you can just
> pull the code. Potentially Emacs developers can improve it. I'm pretty
> much of type "I just scratch my own itches" and to me wcheck is about
> ready. So I'm not interested in new heavy maintenance burden. But I'm
> here and can help.

Thanks.  I just added it to the `elpa' branch, so the 2014.6.21 version
should appear tomorrow-ish on GNU ELPA.

>> I have a question: why does it use window-scroll-functions and such
>> hooks instead of using jit-lock?
> Maybe just because I'm not familiar with jit-lock. Wcheck uses some of
> its features, though. Anyway, the idea is to trigger wcheck read event
> for after any change in window configuration, buffer content, outline
> visibility etc. It's perfectly fine to use other methods if they offer
> similar trigger. After a quick look, maybe through jit-lock-register?

Yes, jit-lock-register is the right entry point.  It should take care of
"change in window configuration, buffer content, outline visibility
etc..."

>> One downside for the user is that ispell.el's M-TAB might not work as
>> well since by the time wcheck's timer runs to discover your typo, the
>> user might "too far".
> Wcheck's "action" feature uses synchronous process to get information
> From its back-end program. Maybe wcheck's version of M-TAB feature can
> be implemented similar way. I've never used M-TAB, though.

I was thinking more of the fact that by the time wcheck has highlighted
the misspelled word, the user might be "too far" already, so we'd need to
tweak the semantics to be "fix the spelling of the last misspelled word,
no matter how far it is", which makes it incompatible with a M-TAB
binding (since M-TAB is used for many other things at the same time, we
don't want this fix-spelling action to constantly hide the other ones).


        Stefan