Spying on helix as a subprocess. Is there a way to get telemetry?

[MatrixManAtYrService]

Hello, I'm working on an app that has to do with annotations. If I'm very lucky, there's already a way to get the data I need. If not, I may fork helix to add it. Either way, I'd very much like to hear some thoughts from people who know helix's internals better than I do.

The Vision

Imagine something a bit like tmux, where helix is running as a subprocess and the user interacts with helix via something less than 100% of the visible area. Except unlike tmux, that extra space is not used to show a different subproces, but instead it's used by the parent process like a margin--you can put annotations there and as you scroll up and down in helix the annotations will scroll up and down also. They're sort of anchored to the text--when you can't see the text anymore, the annotation goes away also.

I plan to wrap vim and emacs (and less and more and...) in this way also, but I'm most excited about helix, so I'm starting here.

The Challenge

I have the text that helix is showing the user, so I have something to go off of when it comes to anchoring the annotations to positions on the "window" boundary, but imagine that the window is very small:

     # the entire file
      this is a line
      and another line
   |  and another line |  # first line shown in user's view
   |  and another line |  # last line shown in user's view
      and the last line

Suppose I want to attach an annotation to the third instance of the word another, but the window is too small for me to know whether I'm seeing lines 3 and 4 or lines 4 and 5. That's a problem.

To solve it, I need:

• the contents of the entire buffer
• knowledge of where the window starts and ends in the buffer

Additionally, I want to know what the selections are so that if the user has highlighted something within helix they can then use the highlighted bounds to create an annotation.

Some Ideas

parse the status bar at the bottom

Realistically, the output is more like this:

      this is a line
      and another line
   |  and another line                    |  # first shown line
   |  and another line                    |  # last shown line
      and the last line
     NOR   path/to/some/file  1 sel 3:1

If the user is viewing a file on the disk, I can maybe tell helix that it's in a large window, but show the user a slightly smaller one, parsing the line that appears on the bottom to learn which file they're editing. This will work sort-of, but I also want the user to be able to paste into a new buffer and then create annotations on the pasted text. In this case there would be no file for me to read. Also, the status line doesn't provide enough data for me to know what they have highlighted.

add a backchannel

Here I'd have a fork of helix which accepted some CLI args which caused it to listen on some network port or named pipe for requests like "what is the current buffer's contents?" Probably there would also be an event stream so that helix could notify the listener of edits or selection changes.

pretend to be tree sitter

I don't know much about the conversation between helix and tree sitter, but it seems like tree sitter consumes much of the same data that I need to consume. Perhaps I could pretend to be a tool that offers syntax highlighting or refactor services and learn what I need to know that way.

---

If you can suggest an approach and point me at code that I'd need to familiarize myself with in order to take that approach, I'd surely appreciate it. If not, well thanks for taking a look anyhow 🙂 .

[dead10ck]

There is a plugin system in the works that will probably be best suited to get this information. For this reason, I would not recommend putting a bunch of effort into forking Helix to add some form of IPC yourself, nor to build something as fragile as trying to scrape the text off the raw terminal output.

That said, there's no concrete timeline on when the plug-in system will be ready or even testable. If you want to start your project sooner rather than later and you also plan on doing it for other editors too, it might be best to start with one of the other editors which already have existing mechanisms to extract this information.

[MatrixManAtYrService]

This is good advice, thanks.

I want to eventually support annotating text by captured by pointing your camera at a piece of paper, so that fragile text scraping that you're trying to help me avoid is sort of the name of the game. But you're right that it should probably be avoided until necessary.