From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Inline completion preview Date: Fri, 27 Oct 2023 16:25:22 -0400 Message-ID: References: <83h6mdfcv2.fsf@gnu.org> <838r7ofw8s.fsf@gnu.org> <835y2sdm5m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a1defe0608b87df2" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9728"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 27 22:26:43 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 1qwTPn-0002Hj-EY for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Oct 2023 22:26:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwTOn-0006Da-5M; Fri, 27 Oct 2023 16:25:41 -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 1qwTOl-0006CS-MZ for emacs-devel@gnu.org; Fri, 27 Oct 2023 16:25:39 -0400 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qwTOj-00084M-Ry; Fri, 27 Oct 2023 16:25:39 -0400 Original-Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c504a5e1deso39170601fa.2; Fri, 27 Oct 2023 13:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698438335; x=1699043135; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=B9QBBRcFwt9mm/26m6MPfg4IDa8ZoqHG9y+9IjTteLk=; b=IdioXxnQamairIMKwgpxEmFz3bqdyYNtj50jjUldtYpAbWMu5n4Wsy0v3iMMFeaECb /y65xLz5nbLBxk/nZmkpHWS9jQS/FldHyh97Uaux0XCDKPX3IdVVIHHJ0MoN9taZNCG2 cOLSNTw47L/ZeCfSbnXzJ0vNH2a32AxiqTZbbDwqiAlqOKuLbhDc/k82sTANunEhneuj 5XtQZVfNf3p686pF6WRgIBk8lgVGEbbdtM6TGuP6befo666ydCSHjgSlx8wJO+DNtewa AZ7O4aiZLhCEotsyLq5x1ypWHDnE6MQa9F5i6MV9wfch36fMowUYQZO/E2Y9OeAhKCsm IXxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698438335; x=1699043135; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B9QBBRcFwt9mm/26m6MPfg4IDa8ZoqHG9y+9IjTteLk=; b=iACoD/eQOEZ0UhXxD6lXox6d2XJi9GadMOo0YX6TqckprWhaUB9bYRH8Jwuna4mL1F m23x2HsEVTMBQyUrnUAeVe9KecGXyfx7EWcahf/9ywl1SfqKXrqnLBz4SOrttmbdFcZE 7Peqs/XXrrXlkHk+FEhXYh2kLNyCpK3AOThaWtZf1oVGczXgSBVcTTmAi60lPGyQPHF3 +naMTnVUmqAGI/Uw5RJqUdZmj49LG6BlcZLfN9twnnMVGjibyjv3gLonUZ1aBuex6kCr yY7oKHvCrB0tKp22/WB6vK0yHKi80054VNgSAlSbuhGLJcqqzmn3HsABsRlC/XAii1JH YNEA== X-Gm-Message-State: AOJu0Yx9HU5R1GhrjWiodgOxq/NcNyvcp/Bx3a5R/gnOl+TsK+H8cIYv sTyPfXy+VapkEESUL8mLKeovnrZyvjOzW3uGIvtD7UbD X-Google-Smtp-Source: AGHT+IFKcMHQdpz67Vv5x1BhPksYHv+V346Ns7QGEG5n5B0L760d5YegdO1r0L+Kgjsz5LIKy9JcOneNKpqMLqHawtE= X-Received: by 2002:a05:6512:15a:b0:507:a701:3206 with SMTP id m26-20020a056512015a00b00507a7013206mr2545392lfo.49.1698438335027; Fri, 27 Oct 2023 13:25:35 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22e; envelope-from=yandros@gmail.com; helo=mail-lj1-x22e.google.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:311942 Archived-At: --000000000000a1defe0608b87df2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 27, 2023 at 3:34=E2=80=AFPM Eshel Yaron wro= te: > [..] For clarity, I'm attaching below a > screenshot showing how such completion preview in an Elisp buffer. > I've seen a few systems try to add this sort of completion preview to editing, and it seems to mostly be based on (ultra-common) mobile device autocomplete UI. The problem with bringing that model into an editor is that mobile device autocomplete is about helping users *append* text to the *end* of a very small chunk of editable text. Those systems also have various ways to "move the cursor", and they're uniformly considered worse, because the interaction model is a bad fit for the user affordances. I've seen a few systems that add this sort of in-line expansion suggestion to actual text editors, where most of the editing happens in the middle, not the end, and the jumpiness that results is, well, it's usually not considered good. (The flashing/updating you get just from adapting the code highlighting to such systems is jarring enough that most editors add extra layers to mitigate it.) I don't know if it's accidental or intentional, but I believe this sort of problem is why you almost always see examples demonstrate mid-text suggestions via pop-ups, and in-line suggestions nearly always demonstrated (as in this screenshot), at the end. Put another way: there are strong reasons to consider Eli's suggestion that Emacs grow/evolve infrastructure to display such suggestions using UI methods beyond "just insert some specially-marked text", even if some users will be happy to have the text quickly/easily plopped directly into the buffer. As usual, I hope this helps, ~Chad --000000000000a1defe0608b87df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 27, 2023 at 3:34=E2=80=AF= PM Eshel Yaron <me@eshelyaron.com> wrote:
[.= .]=C2=A0 For clarity, I'm attaching below a
screenshot showing how such completion preview in an Elisp buffer.

I've seen a few systems try to add this sor= t of completion preview to editing, and it seems to mostly be based on (ult= ra-common) mobile device autocomplete UI. The problem with bringing that mo= del into an editor is that mobile device autocomplete is about helping user= s *append* text to the *end* of a very small chunk of editable text. Those = systems also have various ways to "move the cursor", and they'= ;re uniformly considered worse, because the interaction model is a bad fit = for the user affordances.

I've seen a few syst= ems that add this sort of in-line expansion suggestion to actual text edito= rs, where most of the editing happens in the middle, not the end, and the j= umpiness that results is, well, it's usually not considered good. (The = flashing/updating you get just from adapting the code highlighting to such = systems is jarring enough that most editors add extra layers to mitigate it= .) I don't know if it's accidental or intentional, but I believe th= is sort of problem is why you almost always see examples demonstrate mid-te= xt suggestions via pop-ups, and in-line suggestions nearly always demonstra= ted (as in this screenshot), at the end.=C2=A0

Put= another way: there are strong reasons to consider Eli's suggestion tha= t Emacs grow/evolve infrastructure to display such suggestions using UI met= hods beyond "just insert some specially-marked text", even if som= e users will be happy to have the text quickly/easily plopped directly into= the buffer.

As usual, I hope this helps,
~Chad

--000000000000a1defe0608b87df2--