unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Ash <ext0l@catgirl.ai>
To: "Platon Pronko" <platon7pronko@gmail.com>, help-gnu-emacs@gnu.org
Subject: Re: Moving point around empty overlays with 'after-text
Date: Sun, 09 Apr 2023 20:21:09 -0700	[thread overview]
Message-ID: <66d58398-8eb5-4d89-8e7c-4400f180448f@app.fastmail.com> (raw)
In-Reply-To: <01206f38-741a-b75b-4efe-ecf7c70c6d61@gmail.com>



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.


  reply	other threads:[~2023-04-10  3:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-08  5:46 Moving point around empty overlays with 'after-text Ash
2023-04-08 10:06 ` Eli Zaretskii
2023-04-08 10:14   ` Platon Pronko
2023-04-08 10:10 ` Platon Pronko
2023-04-08 23:06   ` Ash
2023-04-09 12:15     ` Platon Pronko
2023-04-09 14:49       ` tomas
2023-04-10  1:52         ` Platon Pronko
2023-04-10  4:56           ` Eli Zaretskii
2023-04-10  5:22             ` Platon Pronko
2023-04-10  9:56               ` Yuri Khan
2023-04-11  8:49                 ` Platon Pronko
2023-04-11  9:41                   ` Yuri Khan
2023-04-10  5:35           ` tomas
2023-04-10  5:48             ` Platon Pronko
2023-04-09 20:44       ` Ash
2023-04-10  2:00         ` Platon Pronko
2023-04-10  3:21           ` Ash [this message]
2023-04-10  3:31             ` Platon Pronko
2023-04-11  0:22               ` Ash
2023-04-10  5:09             ` Eli Zaretskii
2023-04-10  5:37               ` Platon Pronko
2023-04-10  8:03                 ` Eli Zaretskii
2023-04-10  9:05                   ` Platon Pronko
2023-04-10  5:01           ` Eli Zaretskii
2023-04-10  5:26             ` Platon Pronko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66d58398-8eb5-4d89-8e7c-4400f180448f@app.fastmail.com \
    --to=ext0l@catgirl.ai \
    --cc=help-gnu-emacs@gnu.org \
    --cc=platon7pronko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).