From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Word completion in text modes Date: Sat, 18 Nov 2023 16:53:28 +0100 Message-ID: References: <83h6ljme0j.fsf@gnu.org> <83edgnmaqw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3407"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 18 16:54:05 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 1r4Ne1-0000g5-3i for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Nov 2023 16:54:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4NdX-0003ub-0k; Sat, 18 Nov 2023 10:53:35 -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 1r4NdV-0003uD-Iz for emacs-devel@gnu.org; Sat, 18 Nov 2023 10:53:33 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4NdT-00088k-QR; Sat, 18 Nov 2023 10:53:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1700322810; bh=3c0X3IRbt7HebDAlYF3jHppWWsKFvu7ViAYoXwk7kwU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vtjjH9FFX7iiyQRHI3PKun3lTUInAyLkll0W79+iPeId24LSsI5KllsB/PNmb9A/w fG24Lppf3uV9Uf9i5pKqlejybmXQlzwGgZhPbwk/fEGYj7VZ0jgkr+TNocMsRSDoG8 SjjXMz/DFhadpGT1toT5R3GRHn3F2OmgNtiy/GVfwNUMnKOJIO2Lyj2WnikM4TMGk5 2g/wfoDcNW1uvMJP0xj0gU8xMYHfVY2LhQqk1rHK4X2xNNK/LGFlU92n0nr29ix/HO tteiSzpHCOpPKp03Z7F40j7qEl2Wf7S3sLLu00fPlp37TuOxzQosdAjlB79BI6zCSO eBmSCLzSBOUkg== In-Reply-To: <83edgnmaqw.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Nov 2023 15:50:15 +0200") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:312912 Archived-At: 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 =E2=80=98M-=E2=80=99 to =E2=80=98ispell-complet= e-word=E2=80=99. > > 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 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. The way I see it `ispell-complete-word` predates `completion-at-point`, and in terms of functionality the latter subsumes the former. `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. 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. >> > 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. Absolutely, there's some more work to be done to accomplish what you describe, no magic solutions here. I propose to modernize completion in text modes, opening a door for further developments. > Which is why I prefer to make such internal reshuffling only together > with installing the corresponding extensions, not as separate > "cleanups". Alright, although IMO this has concrete benefits beyond mere cleanup. I'm fine with keeping this patch in a local branch for now, of course. >> 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. Sure, we could also add a `completion-in-region-function` that imitates the current UI of `ispell-complete-word`, although IMO it's not really an ideal interface for completions, so I'm not sure users would like that for the rest of their `completion-at-point` calls. That could be made local in text mode buffers, perhaps. > 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? That's interesting. I guess Emacs could keep a stack of such nested completion sessions and restore the first session when the other ends. I'm not sure if there's something of that sorts in place. Indeed, that's a broader issue than the one at hand. > Something to think about, I guess, if we are going to add more and > more of these completion-at-point frameworks and features. Thanks, Eshel