Expose Editor.scrollTo

[oflisback]

Hi @coddingtonbear, thanks a lot for creating this useful project!

I'm wondering if you'd be willing to add functionality to scroll the active note via (I guess) Editor.scrollTo().

I'd be happy to make a PR for it if you give me some pointers on how you'd recommend it to be done and what endpoints you'd want to expose for it.

My reason for wanting scrollTo is to enable https://github.com/oflisback/obsidian-sync.nvim to in addition to what it does currently, sync the acive note, also sync active scroll position between neovim and the obsidian app.

[oflisback]

To add some more context, this is what enables my use-case in case you think it makes sense in the project.

main...oflisback:obsidian-local-rest-api:main

Happy to fulfill other requirements like openapi doc update etc.

[oflisback]

@coddingtonbear could you share a quick opinion on the prospect of adding something like this?

[coddingtonbear]

This doesn't sound like a bad idea! I don't know what the API for this would look like, though.

Maybe this is something that could be somehow included in the /active/ route and exposed, during a GET via some kind of header. As far as setting the scroll position, though, I honestly can't think of a good place to put that except, maybe, PATCH, but it seems like that'll require me to re-think how we handle PATCH specifications.

[one2three4f]

@coddingtonbear Would love to get this pull request going, I'm not sure if the current api route is something acceptable, but this feature is important for obsidian-bridge.nvim.

If this looks good I can create a new merge request:
main...oflisback:obsidian-local-rest-api:main

[coddingtonbear]

I'm not opposed to the functionality, but I think this will require some more thought around how this might be exposed via the API. I don't think this function really merits its own API endpoint and instead think it should probably be part of /active/.

The problem here is that probably making this a capability of the PATCH method for /active/ is the right choice from an API design perspective, but right now PATCH is a little bit inflexible. I have some vague notions of wanting to make PATCH a little bit more capable of being used for things like this and others (positioning text relative to blocks, updating frontmatter, etc.), but haven't had the time to think them through sufficiently to actually implement anything.

You might be able to help that along if you can think through some ways of adapting the header schemes used by PATCH such that they are a little less specific to the job of positioning text relative to headers. Concreately, the things I'd like to be able to do with patch are:

• Block References
  • Update the content at block references.
  • Insert content relative to block references.
• Headers
  • Position content relative to headers.
• Frontmatter
  • Update a particular frontmatter field
  • Add a new frontmatter field
  • Delete an existing frontmatter field
• Editor State (specific to /active/, and your new request)
  • Update the scroll position
  • (other useful editor state features)

It might be some time before I can give this enough thought to come up with something elegant, though; so any time you can lend to thinking through how that might be done could totally help!

[coddingtonbear]

Related to this: I've put some thoughts here https://github.com/coddingtonbear/obsidian-local-rest-api/wiki/Flexible-PATCH that you're welcome to comment on or add to.