JavaScript Date object is actually worse than I thought

So a few years ago I was complaining about some weird behavior I discovered in the JavaScript Date object. In particular, that new Javascript('2018-01-01') creates an object at GMT/UTC 0. Which is fine, except that the .getFullYear() method gets a value localized to my current time zone, which leads to unexpected results when my date is different than GMT-0.

I was just playing around with this again, and discovered that whether Date creates a localized object or not depends on the format of the value passed to the constructor:

new Date('2018-01-01')
Date Sun Dec 31 2017 17:00:00 GMT-0700 (Mountain Standard Time)
new Date('January 1, 2018')
Date Mon Jan 01 2018 00:00:00 GMT-0700 (Mountain Standard Time)

So yeah, kinda awful.

I don't want to create an account just to browse your website

So I attempted to browse a site on my phone and pretty much got this immediately:

It's a pretty awful UX design, and drives users away from their site (well, this one, anyway) who just want to browse and don't want to create yet another username/password pair to remember.

I just watched the Captain Marvel movie

And I have to say my biggest issue (at least at the moment) is the fact that the characters didn't seem the least bit concerned that there was a creature roaming around loose that had giant murder tentacles that came out of it.

kilo milestone: finished chapter 5 (text editor functionality) and chapter 6 (search)

One more chapter to go...

kilo commentary: changing the interface is bad, especially when you don't need to

Step 122 begins a series of modifications that handles the Enter key inserting a new line. The first step is to rename editorAppendRow to editorInsertRow and add a new parameter.

Now this, in and of itself, is fine. Inserting a line at some arbitrary point in the file is a generalization of appending one at the end, so it makes sense to use the guts of editorAppendRow to create editorInsertRow.

Where things go off the rails (IMO) is in step 123, where we are supposed to go through the code, and modify all the old calls to editorAppendRow to the corresponding editorInsertRow. Now there are only two places to change, so this isn't a huge modification to the codebase. However, I see two problems with it:

• It harms the readability of the code, editorAppendRow has a clearer meaning when we're specifically adding a line to the end of a file
• It's actually unnecessary

We can create a new implementation of editorAppendRow quite simply:

static inline editorAppendRow(char* line, ssize_t linelen)
{ editorInsertRow(E.numrows, line, linelen); }

Much, much better

kilo commentary: In which an array of text lines turns out to be a bad design choice

Way back in step 55, the step was taken to store the file the editor is working on as an array of lines. Steps 119 through 125 are dealing with joining two lines (deleting at the start of a line) or creating a new line with the Enter key. Because of the array-of-lines data structure chosen many steps ago, these are both relatively complicated operations.

In an editor that treats a file simply as a sequence of characters, these operations are as easy (or hard) as inserting or deleting a character anywhere else in the file.

I am reminded of one of Fred Brooks' aphorisms, "plan to throw one away; you will, anyhow." kilo is not something you really fix so much as work through to identify all the mistakes to avoid the second time through.

kilo: The horrible, no good, very bad quit confirmation

Step 115 implements a quit confirmation. That is, the user is prevented from quitting kilo while there are unsaved changes, Well, at first:

    case CTRL_KEY('q'):
      if (E.dirty && quit_times > 0) {
        editorSetStatusMessage("WARNING!!! File has unsaved changes. "
          "Press Ctrl-Q %d more times to quit.", quit_times);
        quit_times--;
        return;
      }

Yeah, that's pretty awful UX right there. Ironically, we're just a few steps away from implementing an editorPrompt function (used to prompt for a filename to save to) which could also be used for saying "You have unsaved changes, really quit? (N/y)", which is how virtually every "real" editor does it.