Live data from Hacker News

Writing an editor in less than 1000 lines of code, just for fun

antirez.com

31–40 of 146 posts

Re: Writing an editor in less than 1000 lines of code, just for fun

#31
post #17

Earlier quoted context omitted.

Yeah but that is so much less usable. Quick, which one is up?

k of course. Having said that, experienced vi/vim users rarely use jk to get around. Instead we use { } / f etc.

{ } are kind of useless if your coding style puts braces on the same line as the function header.

Re: Writing an editor in less than 1000 lines of code, just for fun

#32
post #24

From 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.

Also, he very clearly states he borrowed code from 2 of his other projects that made it faster/easier.

Re: Writing an editor in less than 1000 lines of code, just for fun

#33
post #11
post #9

Earlier quoted context omitted.

j and k behavior may vary depending on your config.

Everything can vary depending on your config, but unless they were explicitly remapped, j and k should pretty much do the same thing everywhere. Have you seen somewhere where that isn't the case?

> Have you seen somewhere where that isn't the case?

I use the dvorak keyboard layout and used to remap (among other things) j and k in vim, since they were not on the home row for me. I stopped doing that after a while though.

Re: Writing an editor in less than 1000 lines of code, just for fun

#34
post #6

Earlier quoted context omitted.

Presumably h, j, k, l will always get you around in vi?

Yeah but that is so much less usable. Quick, which one is up?

I use hjkl consistently in vim and in the shell. Just think about how long it takes you to move your fingers to the cursor keys. You should spend some effort getting used to it, as using hjkl means you can keep your hands in the middle of the keyboard. I have also never had any problems with strain, and I suspect this is part of the reason.

Re: Writing an editor in less than 1000 lines of code, just for fun

#35
post #6

Earlier quoted context omitted.

Presumably h, j, k, l will always get you around in vi?

Yeah but that is so much less usable. Quick, which one is up?

The point is, they are no longer in symbolic memory. At this point they are muscle memory. Quick, which muscle do you use to move your right thumb in? Does it matter?

Re: Writing an editor in less than 1000 lines of code, just for fun

#36
> Let’s say this again, “email client”. The notion of email client itself is gone at this point.

Really? Is it lame to be using an email clients these days?

I still use an email client (Thunderbird) because I can't stand the thought of all my mail sitting forever on Goggle's or whoever's servers. Yes, I know that they could have secretly archived all of my email the moment it was sent or received, and that my privacy is not necessarily enhanced by downloading and storing my mail offline.

That's my main reason, but I can think of many other reasons to prefer email clients to a web interface.

I'm surprised by the sentiment that email clients are passé.

Re: Writing an editor in less than 1000 lines of code, just for fun

#37

Awesome. 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 compl…

The syntax highlighter isn't really a parser, per se. It's just a lexer / tokenizer / scanner / what-have-you, which tend to be fairly compact state machines.

As an aside, I agree with your edit. As someone who started programming back in the DOS days, whenever I do Web development, I'm always floored by how much it feels like one step forward and two steps back. So many simple things just aren't simple when it comes to the browser, and even certain protocols on the backend like FastCGI seem way more complicated than they need to be (SCGI seems pretty nice, though I feel it's missing a way to signal out-of-band information to the Web server, the way you'd use stderr in CGI, for example (though perhaps I'm missing something there)).

As much as I love the idea of sending semantic markup over the wire for document transfer, I can't help but wonder if a more terminal-like protocol would be better for application "delivery", the way we used to do with telnet and BBSs in the 90s, with an upgrade for multimedia. But I digress...

Re: Writing an editor in less than 1000 lines of code, just for fun

#38

Earlier quoted context omitted.

Yeah but that is so much less usable. Quick, which one is up?

I know k is up, because I constantly k in bash, bit the point of using hjkl is exactly not to know which one is what. You set your finger on the keyboard in home position, now your muscle memory does the rest.

>I know k is up, because I constantly k in bash

What is ESC-k supposed to do in Bash?

Re: Writing an editor in less than 1000 lines of code, just for fun

#39
post #24

From 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 you're making assumptions based on your own skills?

Have you seen what e.g. Notch can do in a few hours of live coding?

Re: Writing an editor in less than 1000 lines of code, just for fun

#40

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?

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.

The nice thing about a framework like Unity is that they do have a textfield object that behaves a lot like a standard text object in the .NET Framework. It has a lot of shortcomings but rendering the text is the easy part.
Post reply on HN