emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: jinx


From: Eli Zaretskii
Subject: Re: jinx
Date: Sat, 01 Apr 2023 15:57:53 +0300

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: arash@gnu.org,  rms@gnu.org,  m.eliachevitch@posteo.de,
>   emacs-devel@gnu.org
> Date: Sat, 01 Apr 2023 14:32:33 +0200
> 
> On Sat,  1 Apr 2023 at 14:54, Eli Zaretskii wrote:
> 
> > I'm afraid I don't quite follow.  I actually don't understand why we
> > need END here.  Why not call the function with some buffer position,
> > and let it return nil (meaning don't skip) or a buffer position, which
> > means skip until that position?
> >
> > IOW, skipping text in at least some situation needs to skip multiple
> > words, perhaps even multiple lines, and the skip function should be
> > allowed to specify that in one go.  Right?
> 
> You are making too many assumptions about how the spell checker logic
> works.  What you propose would be really handy for ispell-region and the
> like but is not usable by Flyspell -- for the same reason Flyspell
> doesn't use ispell-skip-region-alist.

This depends on where we decide to plug this feature into Flyspell, I
think.  If we plug this into it before it gets to process the result
of flyspell-get-word, then all we need to do is make sure
flyspell-get-word returns nil for stretches of text that need to be
skipped.

> We should come up with an API that any spell-checking package, present
> of future, could use.

I think what I proposed fits the bill.  But it's just an idea.

> >> jit-spell only uses ispell.el to start a process and jinx doesn't use it
> >> at all.
> >
> > jinx is not in Emacs, so we don't have to solve its problems.  And
> > jit-spell uses ispell.el, so it will be able to use any function
> > there.
> 
> We don't need to solve jinx's problems, but the API should be convenient
> for any third-party package to integrate with, and that's why I brought
> up the example.

I don't see how loading a single Lisp file could be of any
inconvenience.

Adding functions to preloaded packages just because we think they will
make it convenient to some third-party package is not TRT.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]