"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?
> 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 think the Phi page is just including "current state of editor" as well as "aimed for state of editor" in the README.
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.
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.
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
2: https://en.wikipedia.org/wiki/VGA-compatible_text_mode
3: https://en.wikipedia.org/wiki/Terminate_and_stay_resident_pr...
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?
Remember the BKAV splash screen with the running green man in DOS? I have never wondered why a TUI program like BKAV would bother going around just to make a graphical screen just to display a useless running man. Now as I thought about it, it perhaps was because the author faced the same issue, so it's just another graphical program pretending to be a textmode one. The running man is perhaps just because he could do it while he was at it.
I guess I really just meant tedious when I mentioned that kind of work. It's not the kind of usual engineering solution when one first thought about the issue at hand. It breaks most usual assumption about how you solve the problem. It's like when someone writes the whole website in javascript and canvas just to display text because they can't do certain things in HTML.
M68k 7.16Mhz/8MHz Amiga's didn't have a text mode.
The amount of data to copy to scroll text wasn't that huge even in graphics modes.
https://en.wikipedia.org/wiki/PC-Write
Which had ways to load in alternative charsets ..
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?
(i hope my comment didn't come across as overly negative. i am very excited about xi! :-)
At 320x200, a monochrome display is roughly 8K, and 320x256 is roughly 10K. 640x400 is roughly 32K, and 640x512 roughly 40K.
At 1MHz like on a C64 on a PAL system (25 full frames per second) you have roughly 40,000 clock cycles as an absolute upper bound.
That leaves you with roughly 5 clock cycles to copy each byte for 320x200 (320x200 was the most the C64 would do). But the graphics chip "stole" roughly every other memory cycle outside of the vertical blank, so you had roughly 20k cycles to both read the instruction stream, read a byte and write a byte. for the entire screen.
Given that the shortest instructions on the 6502-compatible CPUs are a byte and can load/store no more than a byte, even if there were single byte instructions that'd let you meaningfully load/store data (there aren't), the minimum number of memory cycles would be 64K to move a screen full of text, or more than 3 frames. In reality you need much more to manipulate source/destination addresses. It's been too long, but I'd be surprised if you'd get anything useful done in less than 8 frames, or more than 300ms.
Faster CPU's of course quickly makes it better (as do, potentially, specialized instructions that reduce the amount of instruction overhead), even but then you tended to get higher resolution or more colours to go.
E.g. the default Amiga workbench was 640x200 on NTSC and 640x256 on PAL systems, in 4 colours (2 bitplanes) for roughly 32K or 40K for a full screen. At 7.16MHz on a PAL system, you'd have about 174 clock cycles per byte per second, or less than 7 cycles per byte per frame. The 16 bit data bus means you can spend about 14 cycles per 2 bytes, but then again the CPU gets access to at most half the bus cycles, and so you're back to struggling.
The only reason the Amiga's could reasonably copy a full screen of text per frame without resorting to monochrome and/or the lower resolutions, was special hardware support in the form of the blitter.
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.
