I can make it.
In fact, there are many native text editors out there.
The problem is not creating the editor itself but the community around it. If your editor doesn't supports the most common/basic plugins like linters, debuggers, painters, formatters, code intelligence, etc then it becomes another one in the pile.
Atom became the popular piece of software that is today because of the JavaScript community. Hundreds of high school, college and university students with several hours of free time during the week, writing code in a language that overflows on the Internet, to extend the functionality of a program baked by one of the most popular companies among software developers [GitHub]. This is the type of community that you need to build around your editor in order to make it popular.
Take a look at TextMate [1] which used to be one of the most popular code editor with a graphical interface for Mac years ago. It was open-sourced [2] after its developer put it in maintenance mode. And while it is still being maintained today, not many people are well versed in C++ and Objective-C to contribute to the project at the same speed as a JavaScript programmer would do with Atom.
Citation definitely needed.
If you want linters or code intelligence, there's an emerging editor-agnostic solution for that as well. The guys behind the Language Server protocol[1] realized that making an editor plugin for each language in each editor was inefficient and it slows the adoption of new languages and new editors.
There are plenty of people who keep trying to do that, but a lot of people have moved away from it because “native” means one of:
(1) excluded important platform for developers, or
(2) multiplies maintenance effort and new feature development difficulty by requiring the project to maintain large amounts of platform-specific code for several different platforms (which ends up turning into a platform abstraction layer.)
It's a lot more efficient, in developer time, to choose an existing, well-supported engine that already abstracts the native platform, and focus on developing and maintaining the unique features of your editor instead.
> Any sufficiently complicated program with an extensible cross-platform GUI contains an ad-hoc, informally-specified, bug-ridden implementation of half of a webrowser.
Starting by the fact that not only there are commercial native compilers, Java 9 also started the road to have AOT compilation support with the long term plan to replace the C++ parts with Java (aka System Java, Project Metropolis).
Also there are hooks in Swing and JavaFX to interact with the host GUI, or if using something like SWT a pure native wrapper to host GUI controls.
Unless you mean D, Go, Haskell, OCaml aren't native.