"Phi is a minimal text editor designed to look pretty, run fast, and be easy to configure and use. It's primary function is for editing code."
"The editor is written as if it's a game, so it will probably eat up your battery, as well as run possibly quite slow - especially if you dont have a dedicated GPU - and probably crash frequently."
Can't quite understand what it wants to be, a fast editor that's minimal or one that's like a game and kills my battery and run slow?
My guess (hope) is that Phi is just very new and alpha, and that the author was trying to say "it might eat your homework." Nevertheless, contrast that with Xi, another new, modern text editor written in Rust:
> Incredibly high performance. All editing operations should commit and paint in under 16ms. The editor should never make you wait for anything.
> Reliability. Crashing, hanging, or losing work should never happen.
I don't even think Phi is intended to be anything other than an individual/hobby project. Has the author even commented here yet?
My point is it's not like they are intending Phi to replace sublime, they're probably just doing it for fun. Even if they are more serious, they're being honest about its short comings right now.
There’s and interesting video about Xi called Xi: An editor for the next 20 years. I remember it was a good talk and I would recommend watching it. https://youtu.be/4FbQre9VQLI
We've done quite a bit of performance work, and there's a bit more in the pipeline, especially horizontal scrolling of very large lines. Some of the slowness at the latter is performance bugs in CoreText; we're considering more aggressively working around those. If you're still seeing slow performance, please file an issue.
alright, tried it out on a ~10K line file i have; lines can get pretty long, up to 1000 characters. xi is better than last time i checked -- it can open the file, and is snappy near the top. it slows down a lot near the bottom, which is where the longer lines are.
sublime, for comparison, is very snappy on the file.
i also tried it out on a pathological json file, which is just one line, 429984 characters long. it hung xi for a long time, and when it loaded, was very slow. again, sublime is completely snappy on the file.
probably not worth a bug since i think it's related to long-line support, which i think is already on your radar?
It's mostly a disclaimer for the time being. I'm making no guarantees that the editor will meet those claims at it's current state - but that's the end goal.
I don’t know anything about this editor other than what’s in the readme, but I can make an educated guess.
It can be a minimal and fast editor in terms of text operations.
It can be a heavy and slow editor in terms of screen rendering.
There is no inherent reason why, as it matures, it couldn’t become lighter and faster overall compared to other editors, since it actually uses available modern hardware.
Tight game-loops can be a battery drain, and especially if there are local 'go-lang' things running, inevitably, alongside the SDL bridge. I'd put it in as a clever and educated 'packages may damage your battery' fair-warning, myself.
"The editor is written as if it's a game, so it will probably eat up your battery, as well as run possibly quite slow - especially if you dont have a dedicated GPU - and probably crash frequently."
Can't quite understand what it wants to be, a fast editor that's minimal or one that's like a game and kills my battery and run slow?