What challenges might you have if you wanted to implement something like this inside a game framework like Unity or MonoGame with C#, where it renders everything via DirectX or OpenGL?
Writing an editor in less than 1000 lines of code, just for fun
21–30 of 146 posts
Re: Writing an editor in less than 1000 lines of code, just for fun
#22Awesome. When I saw all the things it could do in so little code, I assumed a higher level language would be used. But, nope...plain old C with the usual standard libraries.
The parser for the syntax highlighting is super cool. Concise and declarative definition of the syntax (well, the keywords, anyway), in HL_keywords, and then maybe 150 lines of code for the parser. I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts. But, it works really well on the C I looked at. Colors are handled in a cute way, too.
All around, I'm just astounded at how concise this is, while still being entirely readable and comprehensible. This isn't clever/tricky golfing code, this is actually human-readable C code.
Edit: Also, I'm struck by how nice/simple the editorProcessKeypress handling is. Trying to do something like this in JavaScript/HTML5 is crazily more complex and verbose. Seeing something like this reminds me how messy user interaction still is in the browser, compared to old CLI and desktop paradigms.
Re: Writing an editor in less than 1000 lines of code, just for fun
#23Earlier quoted context omitted.
I don't know about vi (I think it's still rare on Linux systems), but Vim typically does what is expected from it.
If you ever happen to bork your kernel badly enough to prevent it from booting, you'll find a classic VI pretty quickly, and probably be grateful for it.
Well, not really. My system doesn't have vi installed. Vim, of course, any
time of the day. Stripped Vim (vim-tiny, as Debian calls it), sure, just after
installation. But vi -- no, I don't have it installed.
For quite a long time Linux didn't have vi even ported. There were several clones, like Elvis and nvi (and Vim, of course). Few years ago I learned that somebody took the effort and actually ported traditional vi to Linux. I doubt mainstream distributions cared to include it, though. Why should they? They already have plethora of clones packaged, and those clones typically do much more than traditional vi.
The lesson from this tale is this: don't call vi what is merely a vi clone. vi is a name of a quite concrete project.
And as for kernel unable to boot: if it can't boot, then how the heck am I supposed to run anything under this kernel? Unless you meant kernel can't run OS from local disk. I know Linux well enough to manage to run my things. You would be surprised how much could you hack through if you knew how ELF binaries work.
Re: Writing an editor in less than 1000 lines of code, just for fun
#24From the github page, "Kilo is a small text editor in less than 1K lines of code. [..] The project [..] was written in just a few hours"
Either this has to be a unstructured mess of copy and paste and not worth anyones time or the author is lying about the time he used on this. Both alternatives are unappealing.
Re: Writing an editor in less than 1000 lines of code, just for fun
#25Re: Writing an editor in less than 1000 lines of code, just for fun
#26From the github page, "Kilo is a small text editor in less than 1K lines of code. [..] The project [..] was written in just a few hours" Either this has to be a unstructured mess of copy and paste and not worth anyones time or the author is lying about the time he used on this. Both alternatives are unappealing.
Or, alternatively, the author knows what he is doing, on account of being a very experienced C developer.
Re: Writing an editor in less than 1000 lines of code, just for fun
#27What challenges might you have if you wanted to implement something like this inside a game framework like Unity or MonoGame with C#, where it renders everything via DirectX or OpenGL?
The main challenge is that, even now, in the year 2016, there is no objectively good, fast, reliable way of rendering arbitrary text with formatting in a texture. Hell, even just plain text is kind of a pain in the ass.
And yes, I know about signed distance fields.
Re: Writing an editor in less than 1000 lines of code, just for fun
#28If antirez is reading:
How much time did this take? From start to finish. :)
Re: Writing an editor in less than 1000 lines of code, just for fun
#29Back in the 90's I took a class in Visual Basic, where one of the assignments was to write a rules-compliant tic-tac-toe game. The teacher apologized for the amount of repetitive code we'd have to write to implement it in Windows forms (or whatever it was called back then). I got it down to one printed page.
When I taught V that was a class assignment (along with create a 4 function calculator). I don't remember any of the programs being that long.
For extra credit for people that had problems I'd allow a resubmission of an assignment if you did the logic in a different way. One of the students did a table that let them look up the current board and say what the new move was.
Re: Writing an editor in less than 1000 lines of code, just for fun
#30Earlier quoted context omitted.
Nice thing about Nano is that they arrow keys always seem to do what they are supposed to, no matter the system, shell, TTY, etc. Vi seems to have issues sometimes, and needs extra config
I don't know about vi (I think it's still rare on Linux systems), but Vim typically does what is expected from it.
[deleted]