unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Reuben Thomas <rrt@sc3d.org>
Cc: 44318@debbugs.gnu.org, dinkonin@gmail.com
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 03 Nov 2020 20:50:08 +0200	[thread overview]
Message-ID: <83zh3yb7hb.fsf@gnu.org> (raw)
In-Reply-To: <CAOnWdohQSmRHA4ed9HHwR+W3E074uEPWo_WFm3_wUP50X3+-8g@mail.gmail.com> (message from Reuben Thomas on Tue, 3 Nov 2020 18:27:32 +0000)

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 3 Nov 2020 18:27:32 +0000
> Cc: 44318@debbugs.gnu.org, dinkonin <dinkonin@gmail.com>
> 
>  I think it would be wrong for Emacs to do that, as that would put all
>  the eggs in a single basket, something that is not safe in Free
>  Software world, where packages become unmaintained outside of our
>  control.
> 
> I don't understand this: Emacs, to this day, is happy to import large quantities of code from other project; let
> alone the option of forking/maintaining free software, which is one of its great benefits. And because
> Enchant has such a similar interface to the other supported spell-checkers, the cost of switching is low. For
> myself, I'd be more concerned with bugs or missing functionality in Enchant as a reason to be cautious (i.e.
> I would want to see a phased transition) than about the long-term prospects.

We are miscommunicating.  My point is that if Emacs will depend on
Enchant and won't be able to use the existing spellers without Enchant
being in-between, then we will be in a dire situation if Enchant stops
being developed and bit-rots.  By contrast, with the current code, we
can always tell users to use aspell/hunspell directly.





  reply	other threads:[~2020-11-03 18:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-29 20:25 bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend dinkonin
2020-10-30  7:38 ` Eli Zaretskii
2020-10-30 22:56   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-31  7:29     ` Eli Zaretskii
2020-10-31  7:32     ` dinkonin
2020-10-31  7:50       ` Eli Zaretskii
2020-10-31  8:37         ` dinkonin
2020-10-31  9:17           ` Eli Zaretskii
2020-11-01 22:23             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-02  3:34               ` Eli Zaretskii
2020-11-02  8:14                 ` dinkonin
2020-11-02 15:41                   ` Eli Zaretskii
2020-11-02  8:35                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-02 15:41                   ` dinkonin
2020-11-02 15:43                   ` Eli Zaretskii
2020-11-02 15:49                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-02 16:10                       ` Eli Zaretskii
2020-11-02 21:49                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-03 16:45                           ` Eli Zaretskii
2020-11-03 17:06                             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                             ` <CAOnWdohVdcVffjvptfJUjhRr1jdNn7H3PBzon0LvrR_cguPPow@mail.gmail.com>
     [not found]                               ` <835z6mcqyg.fsf@gnu.org>
2020-11-03 17:19                                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-03 17:31                                   ` Eli Zaretskii
2020-11-03 18:27                                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-03 18:50                                       ` Eli Zaretskii [this message]
2020-11-03 18:53                                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-03 19:39                                           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zh3yb7hb.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=44318@debbugs.gnu.org \
    --cc=dinkonin@gmail.com \
    --cc=rrt@sc3d.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).