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: Mon, 10 Apr 2023 17:22:06 -0700 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> <2314d321-040a-4466-afdb-4317df7e6584@app.fastmail.com> <01206f38-741a-b75b-4efe-ecf7c70c6d61@gmail.com> <66d58398-8eb5-4d89-8e7c-4400f180448f@app.fastmail.com> <934164d0-555e-f018-adc5-0c072d79df91@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="32471"; 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 Tue Apr 11 02:23: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 1pm1n5-0008Gl-1S for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 02:23:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pm1mP-00081b-Al; Mon, 10 Apr 2023 20:22:37 -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 1pm1mN-000819-Db for help-gnu-emacs@gnu.org; Mon, 10 Apr 2023 20:22:35 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pm1mL-0006ty-0E for help-gnu-emacs@gnu.org; Mon, 10 Apr 2023 20:22:35 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C91055C019B; Mon, 10 Apr 2023 20:22:27 -0400 (EDT) Original-Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Mon, 10 Apr 2023 20:22:27 -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=1681172547; x=1681258947; bh=me /7nGmjYWUJVrdGn65UGVLwBEXaws2pTQQV95iG7HA=; b=hHu+ZXTBuV+K8G5F+n n67+kBtjN0j0aEDndoR9bWvGqQHWhlThMobdGlGodIYOEU3ZDtueZzIl0f8JRSMn cRUXh34cZlOUBoWIng5nvQ7JwN5x7PgU8JHRPi9jV8E4QBJd3JKH2YQ8BexFToLt qNuM6cu387XDkxPTqCQTNpvm/iPWR7gRKpeSGto9izNrZTr8T3ixyXI8FhaA4K5k 9+6Op8UlhgfSKo9rpthivEb5Br5J+f1YQGO919KDttYlrFEE+wVgFaXaBBfHXoJr bcXFnJ/iAYd7qqBB/9xl2Kg8il42b3N5sqpx/SMsgWP9WmLjjnRXyv2zBk7OYgeV fnbg== 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=1681172547; x=1681258947; bh=me/7nGmjYWUJV rdGn65UGVLwBEXaws2pTQQV95iG7HA=; b=XE6fdfwIIqv6ln0RaKwmyCaIKByUB KaprJDoFdzz02XxqdOGIwkgapq04B/8zRalKfhuttDiXxq61oUSGHAtO0doaCtoe Fx/knqsvoKtV3Rf5WTkM32ssu4Abv7R3fS5g0ZgkJbH+c93FmucYzPisjfMEtYwv 8u/EzUF5tjlDmNxhPMCimDL+ylxemjuSLKh3kpifotswY/rZqYuxoVY1OIA03aq/ J7i25a0u5dgFrrcfU4iarv1+v+yq6q2K2gw9ETk5M6rI8tNtBEG+Pnf3JUMTzZgq 9HzEwE08UVnRakDOzpe/GOwz05m7VA6LcnU9aEvNSePCUgQQMfM4YYl9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekfedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomheptehshhcu oegvgihttdhlsegtrghtghhirhhlrdgriheqnecuggftrfgrthhtvghrnhepffethfduff ehledtueejgfdvlefgudfgfefggfffleduvdetuefgveevfeefveefnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvgigthdtlhestggrthhgih hrlhdrrghi X-ME-Proxy: Feedback-ID: i98e14743:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88DB1BC007E; Mon, 10 Apr 2023 20:22:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <934164d0-555e-f018-adc5-0c072d79df91@gmail.com> Received-SPF: pass client-ip=66.111.4.27; envelope-from=ext0l@catgirl.ai; helo=out3-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-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:143251 Archived-At: On Sun, Apr 9, 2023, at 8:31 PM, Platon Pronko wrote: > On 2023-04-10 11:21, Ash wrote: > > > > > > On Sun, Apr 9, 2023, at 7:00 PM, Platon Pronko wrote: > >> On 2023-04-10 04:44, Ash wrote: > >>> Yeah, I think doing this "right" might require adding a new property to overlays/strings (or giving an existing property a new value) to enable this behavior and modifying C code. Not sure how viable that is or if it's something the devs would want. > >> > >> I think it's even worse than adding a property to the overlay. You need common point manipulation functions to account for possibility of inlays, i.e. (point) for position before and after inlay will be returning different values, (forward-char) will correctly advance the point from the left side to the right side of the inlay, etc. > >> > >> (on second thought, making (point) return different values for positions around overlays sounds horrifying, because this will break about half of all Elisp code written) > >> > >> But inlay hints seem to be a common functionality for any modern IDE nowdays, so it might make sense to support them natively, without making major-mode developers resort to horrible hacks like described before. > >> > >> -- > >> Best regards, > >> Platon Pronko > >> PGP 2A62D77A7A2CB94E > >> > > > > You could make it so only these special overlays (I'm going to call them inlay-type overlays or just inlays) have weird behavior with (point), but that'd still make things very complicated and I wouldn't do it. A sketch for what I would do is something like this: > > > > When point is on a position with an inlay, the new variable point-is-after-inlay (name subject to bikeshedding) controls where point renders (before if nil, after if t). When inserting text, the inlay moves forward if point-is-after-inlay is nil, and doesn't move if it's t; this means characters appear where you'd expect. > > > > We add a new (forward-char-respecting-inlay) function that sets point-is-after-inlay to t if point is at the start of an inlay *and* point-is-after-inlay is nil, or increments point if not (and the same for backwards). Possibly add an 'always-respect-inlay' mode that makes forward-char act like this, with the caveat that things might break in strange ways. > > > > Each inlay has a 'bias' of 'before or 'after that indicates what point-is-before-inlay should be set to when navigating to it 'from afar' or other cases where there's no good heuristic for where to put it; in general, this should correspond to where the text is the inlay is semantically annotating. > > > > There's probably all kinds of edge cases I haven't thought about, of course. Conversely, an even more general approach that would support multiple inlays in a row would be to have point-is-after-inlay be an *index* (and rename it 'point-inlay-index' or some such). Not sure what a concrete use case for that would be. > > I like this approach. Seems to be mostly backward-compatible. > > -- > Best regards, > Platon Pronko > PGP 2A62D77A7A2CB94E > Thank you :) One problem I realized later is that it's unclear how this interacts with the front-advance and rear-advance properties of a nonempty text overlay; if you know what region of text an inlay 'describes', then you may want to use that region as the start/end of the overlay so it can evaporate if you delete that region. This gets especially hairy if there are *multiple* overlays, or one that ends at the same position another starts... I think for now I'll just use the hack I wrote in the github issue and leave this yak mostly unshorn. Thanks for the feedback :)