Cool :)
But editor without undo/redo is a bit surprising these days, next release?
Writing an editor in less than 1000 lines of code, just for fun
71–80 of 146 posts
Re: Writing an editor in less than 1000 lines of code, just for fun
#72> 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…
I've actually been working on a new email client, and a terminal one at that. Shameless plug: https://github.com/SirCmpwn/aerc
Are you planning to delegate editing and is it purely for reading?
Re: Writing an editor in less than 1000 lines of code, just for fun
#73Awesome. 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…
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes.
A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no connection to a server are actually quite simple, but they're also about as commercially viable as DOS programming (i.e. not at all).
Re: Writing an editor in less than 1000 lines of code, just for fun
#74Re: Writing an editor in less than 1000 lines of code, just for fun
#75Earlier quoted context omitted.
I've actually been working on a new email client, and a terminal one at that. Shameless plug: https://github.com/SirCmpwn/aerc
Very cool! Going by the acronym, are you trying to make a Stallman-ish IMAP client that works well offline and only needs an occasional Internet connection to sync?
[deleted]
Re: Writing an editor in less than 1000 lines of code, just for fun
#76Earlier quoted context omitted.
I've actually been working on a new email client, and a terminal one at that. Shameless plug: https://github.com/SirCmpwn/aerc
Very cool! Going by the acronym, are you trying to make a Stallman-ish IMAP client that works well offline and only needs an occasional Internet connection to sync?
No, just that it does networking on a different thread. This is my main (but not only) problem with mutt. I'm not opposed to going in the direction you suggest, but think more mosh less stallman.
Re: Writing an editor in less than 1000 lines of code, just for fun
#77Earlier quoted context omitted.
Gmail's web client also non-optionally auto-wraps text before sending, which is very annoying when you're trying to send a patch or part of a log file.
That issue basically forced me to switch from plain-text to html emails, and thence to the slippery slope of using italics and the OCD of syntax highlighting my code snippets..
I dread the slow insinuation of "the web" into email. Specifically, the need to use a rendering engine like Blink or Gecko to read an email.
Is there anything I can do to tempt you to switch back to plain-text emails?
Re: Writing an editor in less than 1000 lines of code, just for fun
#78I'm reading the code as a Primer. Fantastic stuff you don't see often.
Re: Writing an editor in less than 1000 lines of code, just for fun
#79Earlier quoted context omitted.
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…
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no c…
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.
Re: Writing an editor in less than 1000 lines of code, just for fun
#80Earlier quoted context omitted.
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no c…
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