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: Inline completion preview Date: Fri, 27 Oct 2023 17:43:17 +0200 Message-ID: References: <83h6mdfcv2.fsf@gnu.org> <838r7ofw8s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17422"; 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 Fri Oct 27 17:44:12 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 1qwP0O-0004Mo-5i for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Oct 2023 17:44:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwOzh-0004on-1r; Fri, 27 Oct 2023 11:43:29 -0400 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 1qwOzd-0004oB-O0 for emacs-devel@gnu.org; Fri, 27 Oct 2023 11:43:25 -0400 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 1qwOzZ-0007mC-7v; Fri, 27 Oct 2023 11:43:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1698421400; bh=l/F5XJxHhd9OcbxMhYU5R878DrGvz4KqW6BWkIjJvGY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AeRdJUsuOcN8t/IhjxUOALHBdueoesd1F+fQG/wU1nXUz7+x6c3jkzPDLK8C+Qmum E0yRzBnpuvni9dk369tHbPVH03ZL/QaTKgKGE05w7kSuUq/3gYe1HqqYpzZyxKmQJj 8BRl9ga8LCGSpHIYrkZ2T4idYC1uNavyHavL2xkGFzZrs81qfmG4rDk1EIcPnqkQ5c AArvmdXNue7loNwswtbGDVYRmt/guAmxRXCazpb6gsVO5TqZvvvj//HYOn8zXt2tC8 BQ85eJVymY+hD7cyGVH/jDtwfpBwAckhK8y9sWs6oggKM8I+prnC38Lg9dFVykulPs I/hYnLJtLP1hw== In-Reply-To: <838r7ofw8s.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Oct 2023 08:52:03 +0300") 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 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:311936 Archived-At: Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: emacs-devel@gnu.org >> Date: Thu, 26 Oct 2023 21:39:16 +0200 >> >> Eli Zaretskii writes: >> >> > I wish people would work on adding to Emacs some a GUI infrastructure >> > for showing such completion candidates like other IDEs do, instead of >> > once again using overlays with after-string properties. >> >> I'm not sure I know enough about the benefits of other approaches, what >> do you envision? > > Did you see how other IDEs implement this display? That's what I > mean. I've used this feature in other editors (e.g. VS Code), but I didn't dive into the implementation, if that's what you mean. Of course some IDEs are not open source so gaining such insights into their implementation is non-trivial :( >> > The result of using overlay strings is simply not visually appealing, >> >> It doesn't seem to me very different from what I see in other editors, >> but I guess that's a matter of taste. > > Then maybe you should describe the use case in more details, because > this could be a misunderstanding of sorts. What are the use case(s) > where the feature you propose would be useful? The use case is this: you're editing some code, maybe it's a language you're not extremely proficient with, and you want your editor (Emacs) to give you suggestions for code that it would make some sense to write. Completion preview does that by showing you a completion candidate you can insert, and displaying it as if you've already inserted it, so you know exactly what it'll look like (you get a preview). As you are typing, Emacs updates the suggestion based on your keystrokes. If you couple that with a good completion backend, you get useful suggestions with a very low friction interface. >> Sorry, that might have not been clear enough, I wrote: >> >> ISTM that the best approach is a simple library that uses only >> `completion-at-point` as a backend, because `completion-at-point` is >> already extensible enough to support a variety of completion >> backends. > > This is an argument from the implementation POV, it basically says > "let's do it because we can". The question I asked is different: why > do we need to invent something new when we seem to already have > similar functionalities that are widely used? To be clear, I think adding Company to core Emacs instead of my completion-preview.el or some such is a perfectly viable solution. I do think there are some considerations in favor of my proposal (see below), and some against, naturally. > A response I expected would explain why those existing packages cannot > support the desired feature, or are too heavy for such a simple > feature, or have some other issues when used for this functionality. Alright, let me review the alternatives: - `fancy-dabbrev` is probably insufficient because it only works with `dabbrev`. It's also only available on MELPA which might make it harder to incorporate in core. - `corfu-candidate-overlay` relies on `corfu`, and I've had a small issue while testing it that sometimes the overlay lingered after point moved, but otherwise I think that if `corfu` would be in core this package would be a fine solution. MELPA-only as well. - `mono-complete` is quite nice IMO, but it's a larger package that comes with multiple backends besides `completion-at-point`, including a bespoke python program that generates word predictions, and I think that something simpler may be more appropriate. It is also only on MELPA. - `company` is great, battle tested, fully featured, and on GNU ELPA. It's an interesting option to explore IMO. It does add an extra level of complexity with its multiple frontends and backends scheme, that I'm not sure is needed in core. - `completion-preview` only provides a completion preview frontend, and only targets `completion-at-point` as a backend, so it benefits from tight integration. Obviously, it is does not provide all of the features that `company` provides, and it isn't very well tested. OTOH it's less than 150 lines of code, so we could actually even add it to completion.el instead of having a separate library. Best, Eshel