matheus —
It was little more than two weeks ago that I was doing some refactoring and some bug fixing that it occurred to me that the scripting api had a somewhat limited design. I thought that maybe I could delegate plugin logic to external code kinda like kakoune and 4coder does.
I thought that it could be cool if plugins were implemented by talking to pepper through stdin/stdout. It would be a nice experiment to see if this was viable. However even before I began prototyping this solution, I noticed that pepper was not yet prepared to talk efficiently to other processes. After a little bit of investigation and after watching some of the early episodes of Handmade Hero, I thought that the best way I could implement inter-process communication, console input and file io, was by implementing some kind of platform layer myself.
I've messed around with the crate `winapi` before and it was fun, so right now I'm taking my time learning more about the underlyings of the win32 api as I implement what will be the windows backend for the pepper editor. I think I'm close to having a decent windows platform layer and soon I'll be able to start porting all the editor logic to use it!
Pepper is about to get even more handmadey!
I thought that it could be cool if plugins were implemented by talking to pepper through stdin/stdout. It would be a nice experiment to see if this was viable. However even before I began prototyping this solution, I noticed that pepper was not yet prepared to talk efficiently to other processes. After a little bit of investigation and after watching some of the early episodes of Handmade Hero, I thought that the best way I could implement inter-process communication, console input and file io, was by implementing some kind of platform layer myself.
I've messed around with the crate `winapi` before and it was fun, so right now I'm taking my time learning more about the underlyings of the win32 api as I implement what will be the windows backend for the pepper editor. I think I'm close to having a decent windows platform layer and soon I'll be able to start porting all the editor logic to use it!
Pepper is about to get even more handmadey!
matheus —
Hello, handmade community!
This is my first blog post here :)
So, as you may know, I've been working on pepper for the last couple of months and it's been coming along very nicely! I've been already using it for some projects and I think I'll be ready to fully switch to it once I finish the LSP integration.
In the mean time, I've decided to make it open source!
While developing pepper, I've learned a lot by browsing the source code of other projects (not limited to other text editors) so I think it makes sense to also let others browse pepper's code.
Also, it's just easier to maintain, distribute and get traction for an open source project.
So, taking inspiration from awesome projects such as Aseprite, I'll go the route of open sourcing the code while offering paid pre-built binaries at itch.io, even though building it is quite easy once you have `cargo` in your system :)
# Some other updates I did in the past weeks:
## Wiki
Pepper now has a wiki: https://github.com/matheuslessarodrigues/pepper/wiki
This is the new home for all of its documentation and I've updated it with lots of new stuff, including examples of how to customize pepper's behavior.
## Better undo/redo edit compression
When a change is made to a buffer, the edit is added to an edit list in a History struct.
However, the common case is having lots of small edits. That is, when you type 'pepper' in inser mode, there would be one edit for each keypress. What we do now is to detect that those edits are right next to each other and 'merge' them into a bigger equivalent edit.
Care must be taken when dealing with multi-cursor edits since, at each key press, those edits will be spread at several buffer locations (and when appended to the edit list, they'd be interleaved). So we let the 'edit merge' code see past the very last edit made and try to find a commited edit that can be merged. If it merges the edits, it must then fix some ranges in the other edits; if not, it simply append the new edit to the edit list.
You can check the code that does the merge here:
https://github.com/matheuslessaro...r/blob/master/src/history.rs#L199
A cool advantage of merging edits is that it's less stuff to send to the language server while implementing LSP's 'textDocument/didChange'!
## Streaming process stdout
This is something I had in the back of my mind for quite some time but never really took the time to implement it out. Pepper has a cool picker ui which lets you fuzzy choose (like fzf and sublime command palette work) items in a list. Before this change, you could spawn a process, wait for it's output and then feed its lines to the picker ui. However it was blocking since you had to wait for the process to finish. So I did a simple 'Task/TaskExecutor' thing that can watch a process stdout and stream it as it becomes available.
Here is its source: https://github.com/matheuslessaro...es/pepper/blob/master/src/task.rs
Now we can add new entries do the picker ui as they become available while always keeping the ui responsive!
It enables lots of cool utilities to be implemented such as:
a fuzzy file picker right inside the editor (before we could only call fzf externally and then let it talk back to pepper)
https://github.com/matheuslessaro...g-recipes#simple-find-file-no-fzf
responsive find in workspace (before we had to wait for ripgrep to search everything before we could show something in the ui)
https://github.com/matheuslessaro...ecipes#simple-ripgrep-integration
That's it for now!
Thanks for check it out :)
This is my first blog post here :)
So, as you may know, I've been working on pepper for the last couple of months and it's been coming along very nicely! I've been already using it for some projects and I think I'll be ready to fully switch to it once I finish the LSP integration.
In the mean time, I've decided to make it open source!
While developing pepper, I've learned a lot by browsing the source code of other projects (not limited to other text editors) so I think it makes sense to also let others browse pepper's code.
Also, it's just easier to maintain, distribute and get traction for an open source project.
So, taking inspiration from awesome projects such as Aseprite, I'll go the route of open sourcing the code while offering paid pre-built binaries at itch.io, even though building it is quite easy once you have `cargo` in your system :)
# Some other updates I did in the past weeks:
## Wiki
Pepper now has a wiki: https://github.com/matheuslessarodrigues/pepper/wiki
This is the new home for all of its documentation and I've updated it with lots of new stuff, including examples of how to customize pepper's behavior.
## Better undo/redo edit compression
When a change is made to a buffer, the edit is added to an edit list in a History struct.
However, the common case is having lots of small edits. That is, when you type 'pepper' in inser mode, there would be one edit for each keypress. What we do now is to detect that those edits are right next to each other and 'merge' them into a bigger equivalent edit.
Care must be taken when dealing with multi-cursor edits since, at each key press, those edits will be spread at several buffer locations (and when appended to the edit list, they'd be interleaved). So we let the 'edit merge' code see past the very last edit made and try to find a commited edit that can be merged. If it merges the edits, it must then fix some ranges in the other edits; if not, it simply append the new edit to the edit list.
You can check the code that does the merge here:
https://github.com/matheuslessaro...r/blob/master/src/history.rs#L199
A cool advantage of merging edits is that it's less stuff to send to the language server while implementing LSP's 'textDocument/didChange'!
## Streaming process stdout
This is something I had in the back of my mind for quite some time but never really took the time to implement it out. Pepper has a cool picker ui which lets you fuzzy choose (like fzf and sublime command palette work) items in a list. Before this change, you could spawn a process, wait for it's output and then feed its lines to the picker ui. However it was blocking since you had to wait for the process to finish. So I did a simple 'Task/TaskExecutor' thing that can watch a process stdout and stream it as it becomes available.
Here is its source: https://github.com/matheuslessaro...es/pepper/blob/master/src/task.rs
Now we can add new entries do the picker ui as they become available while always keeping the ui responsive!
It enables lots of cool utilities to be implemented such as:
https://github.com/matheuslessaro...g-recipes#simple-find-file-no-fzf
https://github.com/matheuslessaro...ecipes#simple-ripgrep-integration
That's it for now!
Thanks for check it out :)