@Antirez please please please let this thing have a future: there is a great need for a modern, simple and usabile CLI editor.
Try vis: https://github.com/martanne/vis
Writing an editor in less than 1000 lines of code, just for fun
91–100 of 146 posts
Re: Writing an editor in less than 1000 lines of code, just for fun
#92cough cough fewer than... cough cough...
He mentioned using cloc to get that metric, so not including comments, formatting, etc.
I think you missed the point: the point is that the correct English usage is "fewer than" when discussing quantifiable items (e.g., lines of code). The title should be "...an editor in fewer than 1000 lines of code."
Re: Writing an editor in less than 1000 lines of code, just for fun
#93Earlier quoted context omitted.
A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.
You're thinking of https://github.com/for-GET/http-decision-diagram
That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.
Re: Writing an editor in less than 1000 lines of code, just for fun
#94Awesome. 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 come…
I started programming in the same era, and feel the same way about "web apps" being a step backwards. The problem is we're building apps on top of a platform originally intended as a document viewer, with kludge upon kludge piled on...
Re: Writing an editor in less than 1000 lines of code, just for fun
#95And yet I read, on Hacker News, a number of people writing how they were often saved by the availability of nano on random systems All the time, but I even use nano all the time on OS X for full on programming, mostly for quick edits or starting things off before I can be bothered opening a full project in Sublime. (Sure, I can 'get around' in vi, but I just don't seem to have the brain for it and nano is 90% fine. I…
I also use nano for my alternative notepad++ in windows. If normal ide i only use vscode in osx.
Re: Writing an editor in less than 1000 lines of code, just for fun
#96Re: Writing an editor in less than 1000 lines of code, just for fun
#97Anyone up for converting it to Swift (3) or Rust?
Re: Writing an editor in less than 1000 lines of code, just for fun
#98> a text editor in less than 1000 lines of code that does not depend on ncurses and has support for syntax highlight and search feature.
Neovim also does not depend on ncurses. Vim optionally links to it for termcap/terminfo access.
Re: Writing an editor in less than 1000 lines of code, just for fun
#99Id like to see people have competitions to write an editor in the most readable amount of lines of code
Re: Writing an editor in less than 1000 lines of code, just for fun
#100Earlier quoted context omitted.
You're thinking of https://github.com/for-GET/http-decision-diagram
That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.
While you're correct that it's a state diagram processing HTTP semantics and not parsing; parsing a text-based protocol is far from trivial. In fact, the HTTP2 FAQ explicitly mentions [1] that reducing parsing complexity was a motivation for going binary with HTTP2.