cl-webkit VS native_messenger

A welcome critique, though unfortunately mostly incorrect :-D! I'll address some of your comments:

1. Nyxt is entirely written in Common Lisp, so yes, any part of it can be reprogrammed at any time. All of our FFI bindings are also written in Common Lisp (https://github.com/atlas-engineer/cl-webkit). In fact, you can even GENERATE bindings at run time. So it is irrelevant what part is invoking C, it is still fully funcall'able at runtime. This is what makes Nyxt not a 'thin veneer', but rather a deep integration which exposes all resources to the end-user (something unique to Nyxt).

2. Our project is a chrome that is agnostic of the renderer engine. We can use both WebKit and Web Engine (Chromium). This makes us resilient to renderer specific problems. If websites decide to ban browsers that utilize WebKitGKT+, we'll have another renderer available to us. We talk about this in our article where we justify some of our technical design decisions: https://nyxt.atlas.engineer/article/technical-design.org

3. Security is very important to us. We rely on upstream providers of web engines (WebKitGTK+, Qt WebEngine) to test and audit secure web engines for us. We can't do everything, you're right about that. For this reason, we give users the choice, and hope for the best!

4. "Lack of flexibility and power"- I think this point is probably the most inaccurate. If you look through our articles you'll see a couple of things that make Nyxt powerful and flexible.

[2] https://github.com/tridactyl/native_messenger

I think you've misunderstood, "native messaging" allows the tridactyl extension to interact with the filesystem and native applications: https://github.com/tridactyl/native_messenger

Hmm, was it opening with a different file encoding before?

You can `:set editorcmd` to something that gives gVim more commands, like is mentioned in this issue: https://github.com/tridactyl/native_messenger/issues/18