> A 3 line file, be it long lines, shouldn't happen
No. It should not.
But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished.
The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API.
I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support.
I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor.
Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript?
But they are atom.io. They can change their API if they need to.
VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release.
Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend.
I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined.
It is unclear where Xi is going so far, that may happen.
feep|8 years ago
No. It should not.
But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished.
The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API.
I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support.
I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor.
Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript?
But they are atom.io. They can change their API if they need to.
VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release.
Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend.
I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined.
It is unclear where Xi is going so far, that may happen.
thinkMOAR|8 years ago