search

driusan / de

A Programmer's Text Editor
MIT License
429 stars 26 forks source link

Exposing filesystem API #23

Open derekparker opened 8 years ago

derekparker commented 8 years ago

Neat idea!

Are there any plans for (or does this already exist) to add a filesystem API similar to acme? It would be great to interact with the editor via an exported filesystem (like acme), that way plugins can be language agnostic, and need only to have the ability to manipulate files to interact with the editor.

driusan commented 8 years ago

You're not the first person to suggest it, so I think there's definitely demand for it. The main problem is I can't think of any good cross-platform way to expose things via the filesystem (I suppose I should look into how acme in plan9ports does it, but even then p9p doesn't work under every OS that Go supports (such as Windows.))

I could probably hack something together with named pipes on UNIX-like systems with a fallback of just polling plain-text files on systems that don't support it, but that would get pretty ugly pretty quickly.

What might me more feasible and only slightly more difficult to work with in most modern languages is a RESTful API plugin based on net/http, which would make it easier to write a non-Go fuse filesystem or 9p filesystem which talks to the REST plugin, but that hasn't happened yet, mostly because my main priority is to get the functionality I still miss from vim implemented.

P.S. Thank you for writing delve!

josephholsten commented 8 years ago

fuse is the closest thing to a standard for this. a non-trivial fuse fs written in go is part of camlistore: https://github.com/camlistore/camlistore/tree/master/pkg/fs

driusan commented 7 years ago

It may also be possible to use a pure Go 9p package for this.

(as far as I know, github.com/Harvey-OS/ninep is the most up-to-date 9p package.)