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: Inline completion preview Date: Fri, 27 Oct 2023 15:18:31 +0300 Message-ID: <83fs1wdzs8.fsf@gnu.org> References: <83h6mdfcv2.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="13009"; mail-complaints-to="usenet@ciao.gmane.io" Cc: me@eshelyaron.com, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 27 14:19:25 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 1qwLoC-00037P-Nu for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Oct 2023 14:19:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwLnH-0005Yj-1z; Fri, 27 Oct 2023 08:18:27 -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 1qwLnC-0005YQ-6t for emacs-devel@gnu.org; Fri, 27 Oct 2023 08:18:22 -0400 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 1qwLnB-0007Cf-Jx; Fri, 27 Oct 2023 08:18:21 -0400 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=jgofyoS4omYE0KsFHTh0+dCUmxL+RFqdFj7mRKPwuNI=; b=nirO7ArTz0LdRnQfdCsy J6wlMl/l721hdivAP4pgwfcResPoSbwEhSfxbwl6bb/s52VZrf/s539Sq80U8fieRmgwKUDz+tdsN ZwWfar3nOi+z2whJm9fXud9a55nzkfsOuN9xGkKeMEMDne0nALL5HpMqDdUPvCEtXRNh/ROv5pSO9 OxM4icRueJ3WDsh8eu7ft2cCvHc4TY4RjnXR0STE5Wn3+TxCWGNMxN3lfcUlge0q0vHQhlIVbYyiC d04uYAchjPyFc4kTbD+qfd5P42aVk08Z7+gegWtH5TOc/KE059H8jvCCikojSvaPl3wgojXACfNy+ FhFbAnZba+6zaw==; In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 27 Oct 2023 12:49:40 +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:311930 Archived-At: > From: João Távora > Date: Fri, 27 Oct 2023 12:49:40 +0100 > Cc: Eshel Yaron , emacs-devel@gnu.org > > On Thu, Oct 26, 2023 at 7:38 PM Eli Zaretskii wrote: > > > > > From: Eshel Yaron > > > Date: Thu, 26 Oct 2023 20:11:17 +0200 > > > > > > I want to propose adding an inline completion preview mechanism to Emacs. > > > > > > By inline completion preview, I mean an overlay that pop ups after point > > > showing one of the candidates for at-point completion. You can view > > > this mechanism as giving you a hint or suggesting a certain completion. > > > > 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. The result of > > using overlay strings is simply not visually appealing, and on top of > > that it causes quite a few complications for the display code. > > I think agree with this, but it should work with Non-GUI Emacs, too right? Ideally, yes. > In a TUI Emacs, there have been these nice pop-up menus for a while. At first > sight the display infrastructure being used there seems suitable for showing > completions, so I wonder if that infrastructure couldn't be refactored > then reused > for a completion popup in core. The text-mode frames should preferably also support this, but we should first think how to do that on GUI frames, and only afterwards how to express the same feature on TTY frames. I also don't see any catastrophe in having features that can only work on GUI frames, although we should try to avoid that. For example, popup menus and dialog boxes were not supported on TTY frames for 2 decades, and we didn't consider that to be such a bad thing. So we could develop the feature discussed here on GUI, and then take the next 2 decades to find a way of doing that on TTY.