From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Word completion in text modes Date: Sat, 18 Nov 2023 18:37:11 +0200 Message-ID: <837cmfm30o.fsf@gnu.org> References: <83h6ljme0j.fsf@gnu.org> <83edgnmaqw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14910"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 18 17:37:52 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r4OKN-0003ez-7n for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Nov 2023 17:37:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4OJy-0002nK-TL; Sat, 18 Nov 2023 11:37:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4OJx-0002n9-ND for emacs-devel@gnu.org; Sat, 18 Nov 2023 11:37:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4OJx-0005OU-Cv; Sat, 18 Nov 2023 11:37:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Tpr+G5O4V7a4NBu0DfSKH1jc+UcrW+B5dRpkxuSfjFs=; b=IsTkEPu9QfkZHGGzSGM/ Urw5/kfT6LXOiBLmg2K2M+PUhMZAjlcKb5F4bXTfpbrBoG6S8iEfRQfDXF6fMUoxYXQC1T0Uhhu0I 4bghMNKYPf382NUIpU2XWakHbAWFN6joECDGj9xKAe5KEEFMrQh9a4az35+Jj0/uGLpiYLzuY5yS+ w/8+DYYoM2fg1y60PjhfBaH7V9Uq9viEIJW/18u+CQDNMWz/jtsO9ObJqWp5c1skRr40vcyq8W2Kp L6ORyKZRQL1ywFh/QymjRVyia9jO1UCEZNg+eFXDjqcTNfMToXTCF42A/VDZG+hCdtr5cxs5Fsu2U Zm2D+lT0+fUh3A==; In-Reply-To: (message from Eshel Yaron on Sat, 18 Nov 2023 16:53:28 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312920 Archived-At: > From: Eshel Yaron > Cc: emacs-devel@gnu.org > Date: Sat, 18 Nov 2023 16:53:28 +0100 > > Eli Zaretskii writes: > > >> It _is_ bound to `C-M-i` in `text-mode`, that's actually even mentioned > >> in several places in the Emacs manual, e.g. in "(emacs) Text Mode": > >> > >> Text mode binds ‘M-’ to ‘ispell-complete-word’. > > > > I tried that in mail-mode and didn't see it bound. But that's because > > mail-mode binds C-M-i to another command. Which IMO is a sign of a > > problem we need to fix: it makes no sense to have a completion command > > bound in Text mode but not in _all_ of its descendants. > > Yes, `C-M-i` is bound to `completion-at-point` in `mail-mode-map`, which > is exactly the binding I'm proposing for the parent, `text-mode`, no? I was talking about ispell-complete-word, not about C-M-i. And if you turn on Flyspell mode, as many users do in Mail buffers, C-M-i gets rebound yet again. > > In any case, back to the original issue: what you say about rebinding > > ispell-complete-word can only be a problem if the new completion is > > incompatible with ispell-complete-word. So we should make sure it is > > NOT incompatible. Then the problem would not exist. > > The way I see it `ispell-complete-word` predates `completion-at-point`, > and in terms of functionality the latter subsumes the former. Not according to your own description, below. > `ispell-complete-word` reuses the spell correction UI of `ispell-word` > for word completion. That's something that I wouldn't necessarily try > to port over to `completion-at-point` for compatibility sake, as we now > have various proper completion (not spell correction) interfaces that > were not available when `ispell-complete-word` came about. If we don't preserve that UI, we will be making an incompatible change, which from my POV is undesirable. It doesn't matter whether we like or dislike the ispell UI for this: compatibility means just that. We could make the old UI an opt-in behavior, but tossing it altogether is not something I'd welcome. > Either way it'd be compatible in the sense that you get the same > completions, and `ispell-complete-word` wouldn't go anywhere so > users could rebind it if they really want to. That is not compatibility in my book, sorry. We should actually offer a very similar or identical UI.