cbrewster / brewcode Goto Github PK

Continued from #1

Right now fonts are accessed via hard-coded paths. This is not portable, we should look into using fontkit.

I put in text highlighting really quickly for fun, but it is done in a very slow and hackish way. It is hardcoded to only do Rust syntax highlighting instead of trying to match the file extensions and text highlighting is recomputed for the entire buffer any time a change is made to the buffer.

I am using syntect for syntax highlighting and it allows for incrementally recomputing syntax highlighting. For example, usually the text highlighting preceding an edit stays the same so that portion can be skipped. Syntect has a way to save snapshots of the highlighter state which can be used to do this incremental re-computation.

I needed to install this https://releases.llvm.org/download.html for clang.

Right now text insertion does not take into account text selection. I am not entirely sure what I want the text editing API to look like yet, but here is my idea for a first cut:

There should be a API which allows for a "span" of text to be replaced with a new span of text. Something like:

fn apply_edit(&mut self, span: Span, edit: &str) -> Location;

A span is two (row, col) pairs where the first pair precedes the second pair (in terms of location in the text buffer). The span can be empty, but represents a location. This is represented by the start and end pairs having the same value. The edit is a new string which replaces the text in the span. The function would return a the location of the start of the edit so that the cursor location can be updated.

One thing I want to do with this editor is experiment with different text editing approaches. I really like vim's modal approach but I think there is some room to create a more streamlined modal editor.

Right now some text metrics are hard-coded (especially those related to hit_testing), we should instead use actual text metrics from the font itself. To do this, we probably need to store the text layout somewhere. Right now, we regenerate the text layout whenever we render, but this is expensive and we don't have access to the result text layout outside of the render method.