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 15:50:15 +0200 Message-ID: <83edgnmaqw.fsf@gnu.org> References: <83h6ljme0j.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="20810"; 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 14:51:17 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 1r4LjA-00057H-P1 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Nov 2023 14:51:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4LiN-0001hN-Fn; Sat, 18 Nov 2023 08:50:27 -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 1r4LiL-0001gt-1z for emacs-devel@gnu.org; Sat, 18 Nov 2023 08:50: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 1r4LiK-0005ds-Ml; Sat, 18 Nov 2023 08:50:24 -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=zkMG31EZX4Q4RunFpd0LAZmx81Tl66k0ml7W/UI8FZI=; b=lIJ+WLjFoYveT85RIRQx LypPt6BAJNmcaUGH0rfFDq/RrBAEZcRp/J8ZAIhIFwJtbeACALlVPS3ypCOH6Mgd2QZ/MGqgPHNZG XzRiRxDfRt/9QkQdLVJaFn/tVTPjjNWea1WS0y0OGjwTG5VwRehNEGZWvvyxDNW3GS0lndwbxWNsy vLHEZMCiGP4MjAbG1Ugu7a2aDm2905SJLhPQ7BiRXnOyp19+18oJJrl6aU4ap4Tjbxlz2GCI5nfEF J8S6h8HlfEbbA8UWt7z8ULPQFeR+xH2obVoI6VWI+nEtZYk7YHJrj0dvVwq4G9DOLMnausYo/aLA7 428w59lYrCakwA==; In-Reply-To: (message from Eshel Yaron on Sat, 18 Nov 2023 14:21:30 +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:312907 Archived-At: > From: Eshel Yaron > Cc: emacs-devel@gnu.org > Date: Sat, 18 Nov 2023 14:21:30 +0100 > > Eli Zaretskii writes: > > > I don't understand why users of ispell-complete-word would need to > > rebind the command. ispell-complete-word is by default not bound to > > any key, so if we still provide ispell-complete-word, the old binding, > > if there was one, should still work, and the only difference should be > > the implementation details? Or what did I miss? > > 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. I guess the developers of mail-mode didn't consider ispell-complete-word an important enough feature, and the question then becomes: will the new text-mode completion-at-point feature be significantly better? 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. > > IMNSHO, such a feature would be much more important and useful than > > the minor changes of UI and reshuffling of the implementation details > > of the sort that you propose. > > My proposal would benefit this aim as well, I think, as we could simply > add another completion function to `completion-at-point-functions`, say > `phrase-completion-at-point`, and users would have their word completion > extended to include such phrase completion with no further setup. I appreciate the enthusiasm, but very much doubt that minor internal changes ("minor" from the POV of user-visible changes in behavior) will eventually bring us important features such as powerful text-mode completion. Infrastructure that makes extensions easy is a Good Thing, but it is not enough to actually make those extensions happen, not by a long shot. Which is why I prefer to make such internal reshuffling only together with installing the corresponding extensions, not as separate "cleanups". > > How would being "attached to the `ispell-complete-word` interface for > > word completion" get in the way? > > See above. My concern here regards users that are used to pressing > `C-M-i` in `text-mode` and friends, and getting `ispell-complete-word`. > If we follow my suggestion of removing this binding, `C-M-i` would > invoke `completion-at-point`, providing similar functionality but with a > different interface (by default that would be the *Completions* buffer, > instead of the *Choices* buffer that `ispell-complete-word` provides). If that is the danger, it follows that we should make the UI of completion-at-point be able to support the UI of ispell-complete-word. Btw, reusing the *Completions* buffer might cause problems on its own, regardless of the ispell-complete-word issue: what if this completion is invoked while typing at the prompt of a command that already popped up the *Completions* buffer? Something to think about, I guess, if we are going to add more and more of these completion-at-point frameworks and features.