[Top][All Lists]

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

Re: ispell.el and pipes

From: André A . Gomes
Subject: Re: ispell.el and pipes
Date: Tue, 16 Nov 2021 22:40:19 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

André A. Gomes <andremegafone@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> From: André A. Gomes <andremegafone@gmail.com>
>>> Date: Tue, 16 Nov 2021 17:42:53 +0300
>>> In the beginning was Ispell (the spelling program) and ispell.el (the
>>> Emacs interface).  The communication is via pipes or ptys.
>>> But today there's Aspell (among others), which provides an external C
>>> API.
>>> Could Emacs leverage it?  What are the pros and cons of pipes/ptys and
>>> the C API for Emacs' sake?
>> The main con is that Someone™ will have to write the code to use the C
>> API and integrate that into ispell.el.  There are also other cons:
>>   . the C API provided by Aspell isn't shared by other spell-checkers
>>     we support (AFAIK)
>>   . using the C API will need Emacs to be linked against the Aspell
>>     library, which makes the build requirements and procedures more
>>     complex
>>   . different versions of Aspell may introduce binary
>>     incompatibilities, whose accommodation in Emacs will complicate
>>     our own code

After some thought and research, the only sane way would be to use the
enchant C API.  It claims to be a wrapper around any spell backend
(ispell, aspell, hunspell, etc).  I can't help with this.  But maybe it
will motivate a soul.

> Ispell.el is quite creepy.  I'm working on some fixes.

Here's the creepiest thing so far, and I must share it so that it will
be properly discussed before I can send patches.

Ispell.el uses ascii characters for the user to choose the right
spelling suggestions.  This was probably OK in the pre-historic era of
ispell (the program), since it only suggests words with
Damerau–Levenshtein distance of 1.  Most of the time, there would be 10
or less suggestions, and that justifies why the documentation
erroneously states that the user must press a digit to choose the right

In reality, the valid ascii characters are those starting at 0 (?0,
i.e. 48) up to ?~ (i.e. 126), minus the characters that are bound to
certain commands obviously.  It is like that since, at least, 1994.  I'm
surprised, to say the least.  Is it even possible to select, i.e. type,
a characters that is above ?~???

A few thoughts below.

Why is there a *Choices* buffer in the first place?  IMO, the
*Completions* buffer should be used.

If the old farts (no offence) insist on using *Choices*, then using
ascii characters is silly.  There should be a variable that gives an
upper-bound for spelling suggestions perhaps.  If that bound would be 10
by default, then just use the digits.  Otherwise, the characters used
should be latin lower-case english letters.  (Typing digits is hard).
Either one or two letters, depending on the number of suggestions.  That
gives as much as (expt 26 2) choices, which is more than enough.


André A. Gomes
"Free Thought, Free World"

reply via email to

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