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:
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:
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:
That's it for now!
Thanks for check it out :)