Expose acme-esque file system

[myitcv]

• Maintain a virtual file system of open buffers. Expose via FUSE
• Expose to other plugins - user will need to ensure that the Neovim process is in a separate process namespace to avoid clashes between multiple instances of Neovim
• Like /mnt/acme
• Offsets exposed via address are line and character offsets?

[myitcv]

Belongs as a plugin idea

[justinmk]

You beat me to it :) I've had this in the back of my head for a long time.

[myitcv]

@justinmk - yes, should be relatively easy to implement as well.

[myitcv]

@justinmk - you might also be interested in #6 if you use X windows (where I will first be building support)

[justinmk]

@myitcv It hadn't escaped my stalking :) I'm primarily interested in the first-class command-oriented interface; I think the "command" nature of VimL is one of Vim's strengths vs a "real programming language". Acme is the ideal implementation of command-oriented interface; absorbing that into Vim could be an important step.

[myitcv]

@justinmk 100% agree. Indeed the very exposing of a MSGPACK API by Neovim opens up the potential for writing plugins, like this, that expose other APIs/interfaces. Will certainly be interesting to see where it goes :)

[myitcv]

@fmoralesc - FYI

[fmoralesc]

I was planning on exposing something like this in plan9-for-vimspace using FUSE. I'm certainly interested in exploring this.

[myitcv]

@fmoralesc - just tidying up the code in this project then I'll be moving on to creating a couple of plugins. This will be high on the list.

[fmoralesc]

@myitcv We could use plan9-for-vimspace as a testbed for this (move it to a separate org, add you as an admin, etc).

[myitcv]

We could use plan9-for-vimspace as a testbed for this (move it to a separate org, add you as an admin, etc).

Sounds great. Happy to put things there. Shall I leave the setup to you as you have the initial code?

[fmoralesc]

Sure, give me a sec.