10 ms·

Show HN: Phi-editor, a text editor implemented in Go and SDL

102 points by felixangell 8y ago

noobermin 8y ago
A text editor in Go rendered in SDL, that's an interesting combination I never thought I would see.
ishaanbahal 8y ago
"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?
- ema 8y ago
  It's trying to be the former but is still the later.
- aorth 8y ago
  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. https://github.com/google/xi-editor https://github.com/google/xi-editor
  - zippoxer 8y ago
    Xi is orders of magnitudes more mature than Phi. You can't compare 76 contributors and 1128 commits vs 1 contributor and 103 commits.
    - Chris2048 8y ago
      Of course you can compare them. One is way more mature, use that.
      - always_good 8y ago
        If you thought they were trying to determine which one to use, you misread the situation.
      - zippoxer 8y ago
        You can also compare apples to oranges.
      - noobermin 8y ago
        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.
  - codetrotter 8y ago
    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 https://youtu.be/4FbQre9VQLI
  - dilap 8y ago
    I love what Xi's trying to do, but last time I tried the OS X frontend, it was very, very slow on large files. I think the Phi page is just including "current state of editor" as well as "aimed for state of editor" in the README.
    - raphlinus 8y ago
      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.
      - dilap 8y ago
        cool to hear. i will check out the latest, and report perf problems, if any. (i hope my comment didn't come across as overly negative. i am very excited about xi! :-)
      - dilap 8y ago
        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?
- primitur 8y ago
  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.
- felixangell 8y ago
  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.
- abtinf 8y ago
  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.
deleted 8y ago
[deleted]
jimmies 8y ago
A text editor that renders text the hard way... Cool! Talking about editors that do crazy stuff, I have a story about the de-facto text editor in Vietnam in the 80s-90s called BKED. That editor runs on MS-DOS and looks just like edit.com [1], except for it displays and allows the user to input text in Vietnamese. Nothing really quite special at the first glance. The Vietnamese alphabet is Latin-extended, and it needs about 100 or so extra characters (caps included) besides the standard Latin alphabet. Thankfully, the extended ASCII character set (code 128-255) was just barely enough to hold the extended Vietnamese alphabet. Consequently, the obvious way to solve the problem of displaying Vietnamese on DOS was to override and redraw the character set in the VGA-compatible text mode [2]. Its rivaling editor, called VietRES, did just that. With some other TSR hooks [3], VietRES made it possible for any text or TUI program on DOS to display and accept Vietnamese. You might have guessed it, RES stands for RESident. However, it has a drawback that is it messed up the TUI of many programs because it had to override almost all of the extended ASCII characters, most notably table-drawing characters. It was an inevitable problem if you ever want to display Vietnamese characters with just ASCII. The problem carried on to even Windows 3.1 and Windows 95. Our Windows-based Vietnamese support program at that time overwrote the MS Sans Serif and turned every '®' in every software install package to an 'â'. Many other character sets had this problem, for example, in Japanese, the '\' was turned into the Yen symbol. Two years ago I thought about BKED and realized that BKED had no problems drawing tables. It could even display bold and italic characters at the same time alongside with regular characters. When I tried to run it on DOSBox, it was clear that BKED did something really clever to get around that. First I thought it might have used the secondary table or something. So I updated my status on Facebook praising whatever the author did. The author of the software -- now an old man -- somehow is a friend of a friend of mine, saw that and chimed in. He said his editor doesn't run in textmode. My mind was blown! It is a full-blown graphical program in Hercules/CGA/EGA/VGA graphics and just pretends to be a text-mode program. It draws every single character in its UI. It had to do it very quickly and economically -- computers in Vietnam at the time were all old secondhand ones imported from the US recycle centers and such. Now as I looked at it more, it was no surprise to me it could also do quite sophisticated mathematical formulas [4]. Thanks to its flexibility, the editor was used to typeset the whole suite of national textbooks on every subject in the 90s. The author also wrote another textbook about Turbo Pascal for college students. Indeed that book was the first I read on programming and Pascal was the first language I learned when I was 12. His work and contribution were well paid off -- he is now a very high-ranking official in the National Ministry of Education. The editor was never open-sourced. I just got his email a month ago. If nothing else, I will ask him to release this gem to our future generations to enjoy. 1: https://i.imgur.com/RZN50oS.jpg https://i.imgur.com/RZN50oS.jpg 2: https://en.wikipedia.org/wiki/VGA-compatible_text_mode https://en.wikipedia.org/wiki/VGA-compatible_text_mode 3: https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program https://en.wikipedia.org/wiki/Terminate_and_stay_resident_pr... 4: https://i.imgur.com/ofhE0TG.jpg https://i.imgur.com/ofhE0TG.jpg
rkangel 8y ago
Text editors and terminals seem to be an interesting space: nobody is quite happy with the status quo, but the status quo is too well established to be dislodged. Everybody keeps attempting their own implementation, but the existing players are good enough (or can be tweaked to be good enough) that no-one gets serious traction.
- coldtea 8y ago
  >* Everybody keeps attempting their own implementation, but the existing players are good enough (or can be tweaked to be good enough) that no-one gets serious traction.* The problem is that not enough people/money are thrown at the problem. Microsoft has done wonders with VSC with its big team -- but in the end of the day it's Node and DOM based. Imagine what something like ST would be, if it wasn't an one-man effort.
- lancebeet 8y ago
  Gary Bernhardt (Destroy All Software) has an interesting talk on this phenomenon for anyone who is interested: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
nspattak 8y ago
I skimmed through the code and I am interested to see what it is doing, so thanks. However from a high design point of view, don't you think that requiring 3D acceleration contradicts the "minimal fast text editor" ?
bionoid 8y ago
I found it interesting to just glance at the code, having never touched Go (but familiar with SDL). Some day I will find the time hack around in one of these new languages, whether it be Go or Rust or Red or Perl6 .. :) I have some trouble understanding the rationale for using SDL_ttf in an editor implementation, though. Did you just cut shaping, bidirectional text and font fallback as acceptable losses, or is it on the roadmap? If so, what is your strategy?
- Ultimatt 8y ago
  Perl 6 is watching you already https://p6weekly.wordpress.com/2018/04/16/2018-16-so-that/ https://p6weekly.wordpress.com/2018/04/16/2018-16-so-that/
gct 8y ago
Seriously quit writing text editors that require GPU acceleration.

102 points by felixangell 8y ago

A text editor in Go rendered in SDL, that's an interesting combination I never thought I would see.

"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?

ema 8y ago
It's trying to be the former but is still the later.
aorth 8y ago
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. https://github.com/google/xi-editor https://github.com/google/xi-editor
- zippoxer 8y ago
  Xi is orders of magnitudes more mature than Phi. You can't compare 76 contributors and 1128 commits vs 1 contributor and 103 commits.
  - Chris2048 8y ago
    Of course you can compare them. One is way more mature, use that.
    - always_good 8y ago
      If you thought they were trying to determine which one to use, you misread the situation.
    - zippoxer 8y ago
      You can also compare apples to oranges.
    - noobermin 8y ago
      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.
- codetrotter 8y ago
  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 https://youtu.be/4FbQre9VQLI
- dilap 8y ago
  I love what Xi's trying to do, but last time I tried the OS X frontend, it was very, very slow on large files. I think the Phi page is just including "current state of editor" as well as "aimed for state of editor" in the README.
  - raphlinus 8y ago
    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.
    - dilap 8y ago
      cool to hear. i will check out the latest, and report perf problems, if any. (i hope my comment didn't come across as overly negative. i am very excited about xi! :-)
    - dilap 8y ago
      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?
primitur 8y ago
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.
felixangell 8y ago
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.
abtinf 8y ago
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.

deleted 8y ago

[deleted]

jimmies 8y ago

A text editor that renders text the hard way... Cool! Talking about editors that do crazy stuff, I have a story about the de-facto text editor in Vietnam in the 80s-90s called BKED. That editor runs on MS-DOS and looks just like edit.com [1], except for it displays and allows the user to input text in Vietnamese. Nothing really quite special at the first glance. The Vietnamese alphabet is Latin-extended, and it needs about 100 or so extra characters (caps included) besides the standard Latin alphabet. Thankfully, the extended ASCII character set (code 128-255) was just barely enough to hold the extended Vietnamese alphabet. Consequently, the obvious way to solve the problem of displaying Vietnamese on DOS was to override and redraw the character set in the VGA-compatible text mode [2]. Its rivaling editor, called VietRES, did just that. With some other TSR hooks [3], VietRES made it possible for any text or TUI program on DOS to display and accept Vietnamese. You might have guessed it, RES stands for RESident. However, it has a drawback that is it messed up the TUI of many programs because it had to override almost all of the extended ASCII characters, most notably table-drawing characters. It was an inevitable problem if you ever want to display Vietnamese characters with just ASCII. The problem carried on to even Windows 3.1 and Windows 95. Our Windows-based Vietnamese support program at that time overwrote the MS Sans Serif and turned every '®' in every software install package to an 'â'. Many other character sets had this problem, for example, in Japanese, the '\' was turned into the Yen symbol. Two years ago I thought about BKED and realized that BKED had no problems drawing tables. It could even display bold and italic characters at the same time alongside with regular characters. When I tried to run it on DOSBox, it was clear that BKED did something really clever to get around that. First I thought it might have used the secondary table or something. So I updated my status on Facebook praising whatever the author did. The author of the software -- now an old man -- somehow is a friend of a friend of mine, saw that and chimed in. He said his editor doesn't run in textmode. My mind was blown! It is a full-blown graphical program in Hercules/CGA/EGA/VGA graphics and just pretends to be a text-mode program. It draws every single character in its UI. It had to do it very quickly and economically -- computers in Vietnam at the time were all old secondhand ones imported from the US recycle centers and such. Now as I looked at it more, it was no surprise to me it could also do quite sophisticated mathematical formulas [4]. Thanks to its flexibility, the editor was used to typeset the whole suite of national textbooks on every subject in the 90s. The author also wrote another textbook about Turbo Pascal for college students. Indeed that book was the first I read on programming and Pascal was the first language I learned when I was 12. His work and contribution were well paid off -- he is now a very high-ranking official in the National Ministry of Education. The editor was never open-sourced. I just got his email a month ago. If nothing else, I will ask him to release this gem to our future generations to enjoy. 1: https://i.imgur.com/RZN50oS.jpg https://i.imgur.com/RZN50oS.jpg 2: https://en.wikipedia.org/wiki/VGA-compatible_text_mode https://en.wikipedia.org/wiki/VGA-compatible_text_mode 3: https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program https://en.wikipedia.org/wiki/Terminate_and_stay_resident_pr... 4: https://i.imgur.com/ofhE0TG.jpg https://i.imgur.com/ofhE0TG.jpg

rkangel 8y ago

Text editors and terminals seem to be an interesting space: nobody is quite happy with the status quo, but the status quo is too well established to be dislodged. Everybody keeps attempting their own implementation, but the existing players are good enough (or can be tweaked to be good enough) that no-one gets serious traction.

coldtea 8y ago
>* Everybody keeps attempting their own implementation, but the existing players are good enough (or can be tweaked to be good enough) that no-one gets serious traction.* The problem is that not enough people/money are thrown at the problem. Microsoft has done wonders with VSC with its big team -- but in the end of the day it's Node and DOM based. Imagine what something like ST would be, if it wasn't an one-man effort.
lancebeet 8y ago
Gary Bernhardt (Destroy All Software) has an interesting talk on this phenomenon for anyone who is interested: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world

nspattak 8y ago

I skimmed through the code and I am interested to see what it is doing, so thanks. However from a high design point of view, don't you think that requiring 3D acceleration contradicts the "minimal fast text editor" ?

bionoid 8y ago

I found it interesting to just glance at the code, having never touched Go (but familiar with SDL). Some day I will find the time hack around in one of these new languages, whether it be Go or Rust or Red or Perl6 .. :) I have some trouble understanding the rationale for using SDL_ttf in an editor implementation, though. Did you just cut shaping, bidirectional text and font fallback as acceptable losses, or is it on the roadmap? If so, what is your strategy?

Ultimatt 8y ago
Perl 6 is watching you already https://p6weekly.wordpress.com/2018/04/16/2018-16-so-that/ https://p6weekly.wordpress.com/2018/04/16/2018-16-so-that/

gct 8y ago

Seriously quit writing text editors that require GPU acceleration.