> unless you limittest generics, most people wont even encounter this.

I don't think my totally normal usage of generics for type safety could be called "stretching the limits." My usage of generics includes using a parameter [V] for OpenGL meshes to introduce type safety with the vertex type. I'm pretty sure that's perfectly normal?

Recently one of my friends tried compiling my project - pan[1] on Windows, and for whatever reason - it doesn't work! stating that it "cannot instantiate 'V'", whatever that means. I've had this error annoy me many times before, but I have no clue what triggers it or how to reproduce it reliably. Call this a 'stable implementation.'

[1]: https://github.com/liquidev/pan [2]: https://github.com/liquidev/aglet

I've run into the "cannot instantiate 'V'" somewhat regularly. Generally it means the compiler doesn't have enough info and defaults to trying to use `V` as a concrete type.

Generally it's not usually an issue with Nim's generics itself, but rather bad error message. Definitely an area for improvement IMHO. Though having used a fair bit of C++ templates over the years, I still find the Nim errors much more tractable after a bit of experience.

There _are_ a few broken limits of Nim's generics, but they are things pushing the type system to a limit.

Former contributor and user of Lite XL here.

It's an awesome little editor. I quit using it though because it seemed like the future direction of the project wasn't very clear, and from a practical standpoint VS Code simply has a better developer experience, but I had great fun hacking around it nevertheless.

One of my favorite things about rxi/lite and Lite XL is just how easy it is to write plugins. Simply create a new .lua file in the plugins directory and monkey-patch whatever you need. And while it might seem like monkey-patching isn't the most clean solution, that's not exactly true — the source code of the editor doesn't need to be cluttered with explicit hooks, and plugins interoperate with each other very well, because one plugin doesn't know about the others' existence. From its standpoint it just modifies the vanilla editor.

This extensibility allowed me to write some really cool stuff, the one plugin I'm especially proud of is lint+ [1], which leverages the immediate mode nature of the UI to draw pretty lint messages atop the text editor (and it even renders Rust's friendly compiler errors with little rails on the left! see issue #3 [2]).

Can recommend.

  [1]: https://github.com/liquidev/lintplus
  [2]: https://github.com/liquidev/lintplus/issues/3

> it even renders Rust's friendly compiler errors with little rails on the left! see issue #3 [2]

Nice!

You might like to show your work on that to https://twitter.com/ekuber if you've not already done so.

It's due to his system settings. This is how text looks like when you have all antialiasing disabled in fontconfig.