Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109910
To: PHP Internals <internals@lists.php.net>
References: <c90bc2ef-8f5d-ee37-6aab-56353bfc1908@gmx.de>
Message-ID: <c4be086b-5219-119c-a2c7-dff5394a61a8@gmx.de>
Date: Wed, 29 Apr 2020 11:52:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <c90bc2ef-8f5d-ee37-6aab-56353bfc1908@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: Enchant 2
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi all!

On 12.10.2017 at 19:18, Christoph M. Becker wrote:

> I've noticed the other day that Enchant 2.0.0 has been released in
> August[1].  ext/enchant does not support Enchant 2 yet, however.  Only a
> few fixes are necessary to make it compile[2], but there is an issue
> regarding the PHP functions enchant_broker_set_dict_path() and
> enchant_broker_get_dict_path(), which rely on enchant_broker_get_param()
> which has been completely removed.  Instead there is now a single
> function to specify the path where to look for the dictionary files:
> enchant_set_prefix_dir()[3].  Apparently, it would be possible to store
> the individual paths internally, and to call enchant_set_prefix_dir()
> whenever a dictionary is requested or checked for existence, thus
> retaining the old functionality.
>
> I have some doubts if this would be sensible, though, because
> enchant_broker_(s|g)et_dict_path() only supported the Ispell and
> Myspell/Hunspell back-ends anyway.  Instead it may be more reasonable to
> introduce a new PHP function enchant_set_prefix_dir() which would
> directly map to the C function with the same name.  Depending on whether
> ext/enchant had been compiled with Enchant 1 and 2, respectively, the
> other function(s) would not be available.  If done this way, the
> constants PHP_ENCHANT_MYSPELL and PHP_ENCHANT_ISPELL should neither be
> available, if compiled with Enchant 2, because they are only useful for
> enchant_broker_(s|g)et_dict_path().
>
> Somewhat related to supporting Enchant 2 would be the question if we can
> lift the requirements to Enchant 1.6.0 (released 2010-04-01).  This
> version introduced enchant_get_version() (which is still there in
> Enchant 2), and would allow us to simplify and clean the libenchant
> version info in PHP info[4].
>
> Thoughts?  Would that require an RFC?
>
> [1] <https://github.com/AbiWord/enchant/releases>
> [2] <https://gist.github.com/cmb69/aa2e5adfc3a08daf16566165d237fba6>
> [3] <https://github.com/AbiWord/enchant/blob/v2.0.0/src/enchant.h#L358>
> [4]
> <https://github.com/php/php-src/blob/php-7.2.0RC4/ext/enchant/enchant.c#=
L321-L325>

Apparently, not much has been changed in the meantime, besides that new
Enchant 2 releases are rolled out regularly.  The latest release of
Enchant 1 (1.6.1) happened on 2017-02-08, and I don't expect to see new
Enchant 1 releases.  This basically means that we rely on an
unmaintained library.  So if nobody is interested in bringing
ext/enchant up-to-date with Enchant 2, it might be best to unbundle the
extension.

Thoughts?

=2D-
Christoph M. Becker