Closed lenormf closed 6 years ago
Food for thoughts: what about having a procfs
approach? A special directory handled by kakoune for each session letting external program set / get stuffs?
/tmp/kakoune/432/commands/buffer-previous/docstring
/tmp/kakoune/432/faces/PrimarySelection
/tmp/kakoune/432/registers/dquote
…
Note that it's a very rough idea and may be totally unpractical for conceptual or technical reasons.
@Delapouite I do really like the plan9 model, however the problem is that there is no portable and reasonably performant way to do that. On linux we could use FUSE, but what do we do on *BSD ?
If I remember correctly ACME used the 9P protocol, which is as a decent number of implementations: http://9p.cat-v.org/implementations
On linux we could use FUSE
As fun to implement as it would be, far from all systems even come with FUSE installed, so it's not a good direction if we're talking about providing a default way to access information.
My plan is to continue with the current model, and improve on it, the big-breaking-tidy-up branch is going to make the format to set/get values from Kakoune robust and well defined. The format itself should be very easy to parse from any language, and should be compatible with the array support in Posix shell (in $1...$N) to make it easy to work with.
I plan to progressively expose additional internal data, such as the undo tree and prompt history, first as read only, then potentially as read/write. That means the Kakoune command language should be considered as a lightweight RPC system.
A developer is attempting to follow this Plant 9 + modal editing path: https://github.com/sminez/ad
Would love to see that 9p approach in Kakoune. I'm thinking it's possible implement a poc as a plugin?
Would love to see that 9p approach in Kakoune. I'm thinking it's possible implement a poc as a plugin?
@eraserhd explored this in https://github.com/mawww/kakoune/pull/3116
Hi,
Some issues have recently been brought up that could find -at least part of- a solution in allowing a convenient way to access the editor's internals from within scripts (including shell scopes). These should be linked here to allow referencing issues linked to this lack of feature, and be used as reference in off-tracker discussions.
1608: access the full value of registers
1605: access an arbitrary option's value without expanding it explicitly beforehand
1604: general purpose plugin API