Switched tree_sitter_list_all_query_results to list Code_Index_Note's matching a Code_Index_Note_Kind in each file
- remove old query types NESTS, FUNCTIONS, TYPES
custom_begin_buffer uses new functions to identify which files to treat as code
implement custom_render_buffer which uses tree sitter data to color tokens
- identify buffer language
- custom_begin_buffer sets up necessary tree sitter state, and kicks off a parse task
- custom_end_buffer cleans up tree sitter data and kills async parse tasks
- tree_sitter_parse_async/__inner uses tree sitter api to get a tree of the buffer's code and stores it on the buffers managed scope
- tree_sitter_write_tree prints tree to a special *tree* buffer
- use new build scripts in 4coder project
It needs an implementation for `free_texture` in 4ed_metal_render.mm (like `get_texture_of_dim`, and `fill_texture`).
We also need to make sure that the texture (`handle` parameter in get_texture_of_dim and fill_texture) is not zero as the original fix expect 0 to signify "invalid texture". More specifically in `4ed_font_provider_freetyp.cpp` there is `if (texture) { fill the texture }`
and in `4ed_font_set.cpp` there is `if ( slot->face->texture != 0 ) { graphics_free_texture(...);}`
Added "code/" in the string that point to the generator so it's easier to find the correct files.
Regenerated the 4 affected files (just to update the comment string).
The crash is caused by dereferencing a invalid pointer to a texture. The D3D11 renderer as a arbitrary limit of 32 textures (there is normally no reason to have more than 2 or 3 textures in 4coder) because it needs to keep track of a few pointer in its state, while OpenGL doesn't (it just uses the id returned by `glGenTexture`). The code that recreate the texture atlas when changing the font size, never frees the previous texture, so both DirectX and OpenGL are leaking texture.
So this fix just frees the previous texture after 4coder successfully creates a new one. If for some reason the new texture can't be created, we continue using the last one. This is better than crashing as we can still use 4coder, but since we can't change font size anymore the editor might be stuck with a uncomfortable font size.
Unfortunately 4coder doesn't expose a way to delete texture outside the platform layer, and the font size code is not in the platform layer. So I had to expose a `free texture` function, which lead me to understand how 4coder generates API in the `generated` folder.
I updated the README to keep that information somewhere since it's not clear from the get go. The basic idea is that there are a few files that you can compile as a small standalone program and run to generate the files. For the graphics api, you need to compile `4ed_graphics_api.cpp`.
I took some time to also modify a little the generator so that the generated file contains the name of the file that generated them, and added a bit of indentation to make the file a bit more readable (even if we're not supposed to modify them).
win32_keycode_init only initialize 30 KeyCode_Ex values (0 to 29) as the code generating the enum only generates that amount (explicitly loops from 0 to < 30).
Fixed duplicated entries in 4coder internal clipboard (Fix from VDK on the 4coder discord).
Removed the unnecessary loop that was there to try to fix the clipboard missing entries (which was fixed previously by removing the `next_clipboard_is_self` variable).
Up until now, several keys were assigned the same key value because the `keycode_lookup_table` array wasn't properly initialized. The values at the end of the array were all set to `KeyCode_Ex0 + 1` which is 112. This would cause several key to be treated as the same key.
In my case the key next to the left shift key ( `<` and `>` on AZERTY) was getting the same value as the `Right Windows key`. But I suppose that the left and right windows key would get the same value too (I can't check this as I have only 1 windows key on my keyboard).
This fix just properly initialize the array. I also fixed a typo in a function name: `keycode_physical_translaion_is_wrong` => `keycode_physical_translation_is_wrong`.
Changed how DXGI factory is handled. I retrieve the one associated with the current DXGI device and adapter instead of creating a new one.
Fixed missing new line in the log at 1 location.
While debugging an issue with the dx11 backend, I noticed that 4coder only clipped rectangles that are outside the screen vertically. Another potential issue (it might be the intended behavior) causes some things to not work with line wrapping, which means that we could have very long horizontal lines, causing a lot of vertices being sent through the render pipeline that will just be clipped after the vertex shader. This causes higher than necessary GPU memory usage, and low performance for things that aren't rendered in the end.
An example of problematic is:
```c
u8 data[ ] = {0,0,0,0,...,0}; // With a lot of zero, and no space between them.
```
This fix just checks that at least one vertex of each rectangle we try to draw is in the screen. It would be better to use the current clip rect, but it's not available at that point in the pipeline. If we want we can modify the API a little to pass it down, as a parameter to those functions.
Using RenderDoc, I saw the vertex count going from over 500K to 13K with this change, and the performance were from 57ms to 25ms. So perfs are not great (but still an improvement), but testing the bounds of 500K vertices is not free. Fixing the line wrapping issue would probably help getting back to reasonable frame rate.
Peter Slattery
flyingsolomon
Simon Anciaux
Ed Ye
Edward Ye
BYP