From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ash Newsgroups: gmane.emacs.help Subject: Re: Moving point around empty overlays with 'after-text Date: Sat, 08 Apr 2023 16:06:42 -0700 Message-ID: <3a1bb709-d00f-49b8-a2c5-d0ac5b6a82c4@app.fastmail.com> References: <9b1654ec-1ac6-4936-860b-2d77dcc4dac7@app.fastmail.com> <28954f0d-205d-b322-4a43-cf4481d1266e@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32442"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6 To: "Platon Pronko" , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 09 06:10:43 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 1plMO2-0008FM-Cy for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 09 Apr 2023 06:10:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1plMNR-0004BM-Pu; Sun, 09 Apr 2023 00:10:05 -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 1plHeP-0002cU-Of for help-gnu-emacs@gnu.org; Sat, 08 Apr 2023 19:07:17 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plHeN-0006gF-4W for help-gnu-emacs@gnu.org; Sat, 08 Apr 2023 19:07:17 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 17CF43200708; Sat, 8 Apr 2023 19:07:13 -0400 (EDT) Original-Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Sat, 08 Apr 2023 19:07:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catgirl.ai; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1680995232; x=1681081632; bh=8g 9MG9chtJ2Fzwhu/ptN/9L0+pwvF2jlXuD6N1nauLc=; b=EvHAD3L+FrcQTTPX+n TWOcCTzR7lTky1knbSMp1NZ9HvXxPvrEIBEvqBuFgS5kz0I5B5PqLayIeJBeo+z2 wDgbfduNbPzGRlUqRPXKgLJKrrw0N5Vh1XUZSw0vsEN4k0qbkJH4tf3cj7zcUO1q BKE//AXRrVfU7wpfybG8j9yM2ofJ++rDEcxlRBf72vB8oAweqxrKQN97lCgecMbI a1MGYZS1tKaMjVMPTPVrx51fkXJGqILUwp+afB9ncg+suMVC5ZxmdI47dtqDI1fd jJmIvG5V3NpwGdpT5UdzhhxVjGJtavoIHo7YTwAGpnSRy7diy7lgoGytB27UyMlW YTEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1680995232; x=1681081632; bh=8g9MG9chtJ2Fz whu/ptN/9L0+pwvF2jlXuD6N1nauLc=; b=tzlxqFHvjQ4RIR/HCwLDqcv7wp7lk y7Mpb288PoJ+3cH/cVdBFxHbYVC4mv5moUppAOcEH7KsZpgOKiep6m6ZBva2+hAn 6I9KECXrerwhGx8Zd4UoWehr/LGCv9R/cfSVHD3Sx0SaL8FVwf9scSAhsbjcBuY4 q1F5y/mYvEWhiwdZc+Y0QWwZX7D+EGIDdqpC6cW/pbL0rAWs+UoITk4i8Pk5cG/3 wcBIkaxwZ3UE0OOmw5LgYEjmnVgTwrhd0JSu0pHHbJV5nZjI5sp1z5+ywXk9fRRD NW6PEFN6mR9lZkFOzD9ZEV1o3k7dpi8+53Wei9RD4WkvbpT1faL6LgkSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejkedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomheptehshhcu oegvgihttdhlsegtrghtghhirhhlrdgriheqnecuggftrfgrthhtvghrnhephedthfekud etheeitdfhgeehjeehudekueefhfeuleefvefgtdevkeetkeelieegnecuffhomhgrihhn pehgihhthhhusgdrtghomhdpghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegvgihttdhlsegtrghtghhirhhlrdgrih X-ME-Proxy: Feedback-ID: i98e14743:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67135BC0083; Sat, 8 Apr 2023 19:07:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <28954f0d-205d-b322-4a43-cf4481d1266e@gmail.com> Received-SPF: pass client-ip=64.147.123.24; envelope-from=ext0l@catgirl.ai; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 09 Apr 2023 00:10:03 -0400 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:143229 Archived-At: On Sat, Apr 8, 2023, at 3:10 AM, Platon Pronko wrote: > On 2023-04-08 13:46, Ash wrote: > > https://github.com/emacs-lsp/lsp-mode/issues/3263 is a bug in lsp-mode (emacs's > > own eglot has the same bug as far as I can tell) that appears to boil down to > > the behavior of emacs overlays and after-string. That is, if your buffer looks > > like > > > > let my_value{: Vec} = vec![0, 1, 2]; > > > > (where the curly braces indicate the after-string property of an > > overlay), you need to put your cursor *after* the overlay to > > insert text at the end of the variable name, which comes *before* > > it, and it's impossible to put your cursor immediately between > > the overlay and the preceding text. I assume the behavior the > > user desires is that you can put your cursor either immediately > > before or immediately after the overlay and insert text, and that > > pressing the left/right arrow would move you over the overlay but > > leave the actual position of point unchahnged. > > > > My suspicion is that this isn't fixable just by setting the right text/overlay > > properties, since both the cursor locations immediately before and after the > > overlay actually correspond to the same location in the underlying string. But > > I'm not good at text property arcana. Any advice? > > Github issue has some suggestion about how it could possibly be done, and the poster > rightfully notes that the solution is nasty (essentially catching the event of cursor > moving 1 char forward, tweaking overlay properties and resetting the cursor back). > > Does it actually make any sense to put the cursor right after the overlay? > > In my opinion the easier solution would be to always put it before the overlay - this way > when the text is typed it is inserted right before the cursor, not somewhere else. > > However there are problems with that as well, because right now there is no correct way to > set cursor position when near the zero-width overlay > (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62540). > > -- > Best regards, > Platon Pronko > PGP 2A62D77A7A2CB94E Yeah, that's my message, hence why I was asking if I was missing something :) In some cases it makes sense to put the cursor after the overlay; for example, when invoking a function, the overlay can look like some_function({argument_name: }some_value) in which case you'd expect to be able to put the cursor after the overlay (to edit the value) and before (to add another argument to the list). Both cursor positions would correspond to the same location, but you're doing something different semantically. So I would expect to be able to type 'another_value, ' before the overlay and 'foo' after and get some_function(another_value, {argument_name: }foosome_value) and not some_function({argument_name: }another_value, foosome_value) In practice, I think for the existing overlays in rust-analyzer's inlay hints there's a 'preferred' cursor position (start for type annotations, end for param name annotations) where the user will want it 80% of the time, so it could set things up based on that. Might also investigate the nasty solution and see how clean I can get it and see if it's expensive CPU-wise.