From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Platon Pronko Newsgroups: gmane.emacs.help Subject: Re: Moving point around empty overlays with 'after-text Date: Tue, 11 Apr 2023 16:49:10 +0800 Message-ID: References: <9b1654ec-1ac6-4936-860b-2d77dcc4dac7@app.fastmail.com> <28954f0d-205d-b322-4a43-cf4481d1266e@gmail.com> <3a1bb709-d00f-49b8-a2c5-d0ac5b6a82c4@app.fastmail.com> <22b315db-39eb-80b6-1a7c-127f5e703dc1@gmail.com> <83o7nwl4ig.fsf@gnu.org> <571d4b51-a29f-23a6-5b29-ca5870af1c8f@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7527"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Cc: Eli Zaretskii , help-gnu-emacs@gnu.org To: Yuri Khan Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 11 10:50:19 2023 Return-path: Envelope-to: geh-help-gnu-emacs@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 1pm9hi-0001lA-Ku for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 10:50:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pm9h7-0000mj-Jk; Tue, 11 Apr 2023 04:49: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 1pm9gy-0000lU-BE for help-gnu-emacs@gnu.org; Tue, 11 Apr 2023 04:49:32 -0400 Original-Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pm9gs-0002gs-3J; Tue, 11 Apr 2023 04:49:30 -0400 Original-Received: by mail-pj1-x102a.google.com with SMTP id y11-20020a17090a600b00b0024693e96b58so6129579pji.1; Tue, 11 Apr 2023 01:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681202955; x=1683794955; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GjsMD0aKnKbRCY7H/nBAVfRz2EcgI2q4X3iU7CSodtE=; b=oGVDkhd/biD2DLhrrg9u1H4fQCKxGIC3MBsgA7U5LFOJtA67kQFvU1i6ZM5yshYQYA 0XlDQCO+eZTscYZHprCstyy6OP0hTlXLwbUOq5bcvhR1V+4TYCfoQEcaYt1GTGXyQOxU tZTYnxQCVY0jv3uWoG7DBF4wCFRVi0ijkiNIvGw+2SteKgoaRgfizMaOzvOP7wktHGEK aPw4mFHwfkbCW+M5jZWWe5bO+5Ajzm8DVyBX1YD0cPo2nV0w7XMDsjCxMJMeAdhZbBMr U9axbUEmvlh9TWQqr4h1w34NUpz/jbknSIkcS7z6uzTDnyzYWZBs3Q2RX3TNtFI+PsrP zeVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681202955; x=1683794955; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GjsMD0aKnKbRCY7H/nBAVfRz2EcgI2q4X3iU7CSodtE=; b=XmPUPYk3WkrQ+Jp/L7+CXK8fzMLHO3vcmotwlIL9onpvamUKK5LDevzgVvOCNqGjKO qnC6/Mwbu5oAFQUC0VI72xuBw7DK5a56UByGSGq1lWIgaZsxGqb7DuzOOcx8+1ooRQWa 871PApqIYtlnjeilQaTf6RrSmtPq6iysIeZY6qk02STzjMMDg2U6jwPGqFGtdrXeTFHJ ILlua2aCApvJxXposTURYxDyoE0x0b/HL47Q/yJ/ICVf+bUbgNDU8KsdSCRZhdEJ4AiZ fgdZ4kPyxDW4OeYEt8+egFCmtWNF1rJYACVvG69L33UsEYKCDXs2AOurexhfgJVaDuKc 7bow== X-Gm-Message-State: AAQBX9f2LCFdHKuB73GJKApnWGRB00CtMtpRaUsP1dyrRHB31BBeZmuH 2cNuu2r5xs8ZeptsTpK++8E= X-Google-Smtp-Source: AKy350ahkIt7w3gyfKoaqEjXu37M8D8s7sP8Hc2xHs69XfKUBnbikuc520m/KGKlVptUR/UAA1x++Q== X-Received: by 2002:a05:6a20:1bc2:b0:d3:72c6:b018 with SMTP id cv2-20020a056a201bc200b000d372c6b018mr12777117pzb.39.1681202955187; Tue, 11 Apr 2023 01:49:15 -0700 (PDT) Original-Received: from [192.170.1.133] ([103.24.106.35]) by smtp.gmail.com with ESMTPSA id o12-20020a056a001bcc00b006328ee1e56csm5682499pfw.2.2023.04.11.01.49.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Apr 2023 01:49:14 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=platon7pronko@gmail.com; helo=mail-pj1-x102a.google.com X-Spam_score_int: -52 X-Spam_score: -5.3 X-Spam_bar: ----- X-Spam_report: (-5.3 / 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, NICE_REPLY_A=-3.246, 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:143252 Archived-At: On 2023-04-10 17:56, Yuri Khan wrote: > You’re talking about typing “41, ” as if it were an atomic action. In > some cases (e.g. pasting from clipboard) it could be, but normally > you’ll be inserting characters one by one, and it might be instructive > to look at the buffer contents and expected inlay behavior through the > intermediate stages. > > 0. Base state: > > def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {} > test({a1=}42) > > 1. You type “4”. Depending on how the editor interprets the insertion > around the inlay: > > 1a. The editor inserts the digit 4 at the position where the inlay is. > The text is now “test(442)”. Syntactically, you just changed the > argument value, so the inlay should stay before the newly inserted > character. > > def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {} > test({a1=}42) > > 1b. The editor lets you insert the digit 4 before the inlay and > somehow knows it is separate from the “42” that used to be the first > argument. The text is now “test(4█42)” where the block represents some > kind of separator. Likely, this text is invalid syntax, so the inlay > is now technically incorrect. > > def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {} > test(4█a1=█42) > > 2. You type “1”. Same thing as “4” before, only in case 2a the > insertion is no longer adjacent to the inlay so the issue does not > even arise. In case 2b, you now have “test(41█42)” in the buffer and > “test(41█a1=█42)” in the view. > > 3. You type “,”. > > 3a. The text is now “test(41,42)” and syntactically it’s a call with > two arguments. The inlay for the first argument stays right after the > opening paren; a new inlay appears after the comma and before the 42. > > 3b. The text is now syntactically well-formed, so the IDE can update the inlays. > > def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {} > test({a1=}41,{a2=}42) > > 4. You type a space. > > For typographical reasons, a well-designed grammar will infer the > space to belong to the separator, not the argument expression. The > inlay will shift after the space. > > def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {} > test({a1=}41, {a2=}42) > > > Basically, after working out the above, my question is: Why is it > important to let the user choose whether to insert newly typed > characters before or after the inlay, if the inlay is going to be > updated and repositioned based on the resulting buffer text? > Alternatively, why is it important to let the user bring the buffer > into an invalid state that may even be unrepresentable in text? You are discussing the technical part, and there you are correct on all points. Of course, from the buffer standpoint all my examples are equivalent and it makes absolutely no difference on what side of the overlay the cursor is. And after the user types something the well-implemented mode will remove the overlay and everything will be fine. I'm talking more about the user intention, before he actually types anything, and consequently the confusion he will temporarily experience when he will try to execute this intention. We here in Emacs mailing list understand the internals quite well and thus can understand that the overlay is zero-width and cursor position is actually the same on both sides. Less-enlightened user won't - for him the inlay is something tangible, present in the buffer the same way as the characters are present in the buffer. And in the discussed example the user can have two different intentions: Intention 1: prepending something to argument value. In this case he will want to position the cursor after the overlay: test(a1=42) test(a1=142) (here and after - I'm intentionally omitting the braces around the {a1=} part, to illustrate my point better - usually the inlays look very close to syntactically correct code, so when the developer is working with the code he is likely to treat that "nonexistent" code very similarly to the real one, as if it was actually present) It will not make sense for him to want to position the cursor before the overlay. Look how confusing his intuition would be if overlay was setup to show cursor before: test(a1=42) // User is confused. // He might want to move cursor to the right, // but then it jumps into the middle of the next argument: test(a1=4) // He returns back: test(a1=42) // User types "1". Here's how his brain predicts the next state of the buffer: test(1a1=42) Of course once the inlay is hidden, everything is back to normal. But user is already slightly frustrated. Intention 2: prepending another argument. In this case he will want to position the cursor before the overlay: test(a1=42) // User tries to type "a0=1," (let's imagine there was such an argument) test(aa1=42) // More typing test(a0=1,a1=42) Here, if the overlay was set up such that the cursor is shown after, the user's intuition would be screwed again: test(a1=42) // Why my cursor is between the argument name and argument value? // Move left: test(a1=42) // Something is broken, let's move back: test(a1=42) // Let's try typing "a0=1". Here's the intuitively expected state of the buffer, completely garbled: test(a1=a0=142) In all these examples nothing horrible happened - after a short struggle the user will be able to fix the issue and continue on his way. But such issues contribute to the overall feeling of the editor, and I would be sad if Emacs was leaving people with the feeling of "ever so slightly broken". We can be better than that :) (and in "we" I include myself - I'm not just idly discussing, I will be willing to go into the code and create a patch if we can agree on how it should be patched, if it should be) Oh, and by the way, even if we disregard all of the above - we still don't have any well-defined way of positioning the cursor around the zero-width overlay. The way it works currently is it's either broken and cursor is shown on the wrong side, or the code relies on some side effect of overlay implementation (c.f. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62540).