Revert "When creating a task while viewing a tag, the new task has that tag"

Revert c948f3b419535ad0774392636d2fd1166fb6e312 in spirit.

This often isn't the right thing to do.  It's especially
counter-productive in the while viewing the "Project" tag -- new
sub-tasks in projects are not themselves Projects.

h/l to move between task nesting levels

Rename: moveCursor → moveCursorVertically

"vp" to view the tag "Project"

Nested tag view

Factor insertInPriorityOrder() out of setPriority()

When creating a task while viewing a tag, the new task has that tag

Wrap task description before going into tag space

Don't assume input is first child

"i"nbox view shows "u"ntagged tasks

Task-level operations should work even when a tag is focused

Tag view

resetView

currentTag helper

Put state colors in one place

Invert priorities

Making "high" priorities low numbers was a mistake.

1. Things that come freshly to attention are much more often among the
   highest priority things and are very rarely lower priority that
   everything else being tracked.

2. Logging the completion of an already-done task, a task that was *so*
   high-priority that it was completed before even being tracked here,
   feels bad when it ends up initially marked as lowest-priority-ever
   unless some additional action is taken.

3. Marking a new task highest-ever-priority is fairly common and
   oughtn't cost two log entries.

4. All the high priority tasks ever tracked oughtn't be fighting over
   the smallest-representable IEEE floating point values, as they all
   try to get slightly closer to zero. When highest-priority is now(),
   these tasks get nicely spread out over the keyspace.  This helps with

   * keeping priority values integer-rounded, which helps with
     * serialized log size
     * log parsing simplicity (clients needn't support scientific notation)
     * preventing underflow

  * making the priority-sorted 'done' views be not-completely-useless
    as all the tasks that have ever been high-priority get haphazardly
    interleaved near zero.  Instead, it becomes almost chronological.

This change does rather a lot of violence to current users of this tool,
inverting their displayed task list order & making no provision
whatsoever for gentle migration across this change of an implementation
detail.  This is fine, because there's still only one user of this tool:
the author.  Breaking changes like this will not be tolerated after
deployment.

Scroll to top when entering a new task

Edit should still work when a tag has focus

^e and ^y for scrolling without moving the cursor

Mostly ignore inputs when control is pressed

"G" to Go to the count-prefixed line.  eg: "1G" to go to the top

vi-style count-prefix for task movement

vi-style count-prefix for cursor movement

Redo

Factor out some boilerplate in UI

"va" to view all tasks

... except deleted tasks.  You have to go to the deleted-tasks view
specifically to see those.

Style the state-dates

Show dates on non-todo-state tasks

Eg, this is the completion date for completed tasks, etc.

Declare character encoding

This quiets a warning in the Firefox console.

"sm" and "vsm" for someday-*maybe*, rather than just "s"

The "maybe" in "someday-maybe" feels really important.  It feels
importantly different than "someday".  It definitely feels worth the
extra keystrokes & extra keystroke state logic.

Rename inputStates to be less semantic and more concrete

"T" to make task "Top" priority

Factor out makeTopPriority

"x" removes the first tag if a task, rather than a tag, is selected

Press "x" to remove tags

Undo tag

Accept "vv" for jumping to the default view

Disallow all-spaces task descriptions and tag-names

Don't listen for keystrokes until log replay is done

Provide a visual indicator of the current view-state

h/t https://css-tricks.com/body-border/

Keep tags visually associated with their task

If a task's tags line-wrap, the shouldn't go into the next task's space.

Keep tags sorted

Color tags

Keep description in its own span

Tags broke task.textContent being an easy way to get the task
description, which editTask was using.  This restores neatness & fixes a
bug in which tag names were slurped into the edit-task buffer.

Do more filtering in faster browser-native code

The tag-input box appearing should not move other tasks' tags around

Fix: Escape aborts tagging

Disallow empty-string as a tag name

Use previous tag name as default new tag name

This makes tagging a bunch of tasks with the same tag easier.

Don't create duplicate tags; Tagging is idempotent

Don't attempt to create duplicate tags

Add tags

Avoid children[0]

Sort log apply actions

Use classList to set class

Change "todo" view key "t" -> "q" ("queue")

Don't select-all the task description when beginning editing

I find that
 * most edits are more gentle than complete replacement
 * I consistently reach for the "end" key to begin editing
 * If I want complete replacement, ^A is easier to type than "end"

Escape to abort a task edit

Always return to command mode (leave input box) after creating a task

Even in other views, where the just-created task cannot accept focus.

undoLog is private to the UI

Views: Show tasks by state

Allow browserUI private fields

Use CSS for filtering the view

Always set state attribute

Leader key "v" for selecting views

Commands are in command mode

Use a monotonic clock

Generally assume that clock values always increase to simplify reasoning
everywhere clock values are used.  Then enforce that assumption.

Clock values don't really, truly always go up because page reloads &
multiple devices, but since I'm not currently planning to spend the
effort that would be required to perfectly handle this in all cases,
making it happen in fewer cases is a win (rather than just making bugs
I want to fix harder to reproduce).

Explicitly remove the completeEdit onblur event listener

When the completeEdit is invoked by keystroke, we don't want it invoked
a second time as a result of its own action removing the input field.

Firefox does *not* call the "blur" event when a focused input element is removed.
Chromium *does* call the "blur" event when a focused input element is removed.

So this is needed for Chromium.

Edit task descriptions

Don't change state if it's already in that state

Change focus in BrowserUI, never in Model

We don't want updates coming in from network sync to move focus around.

Tasks have one state.  Enables undo for state changes

Undo for task creation and reordering

Never mind about Destroy.  Deleting is just state "deleted"

It doesn't get erased from the log anyway.

Full-width input box

Start with focus on top task

Control-enter to make new tasks top-priority

Allow Model to return values through UI

Initiate task creation with Enter key rather than form submit

This will let us detect modifiers on the keystroke.

Eliminate createTask.  It's part of addTask

In the spirit of maintaining the invariant: all tasks are in the DOM; no
loose, floating tasks.

Re-order tasks

Put tasks in a div

Sort Model methods

Factor out task offset logic

Fix moving focus over completed tasks

It sure would be nice if we could just trigger whatever the browser does
for tab and shift-tab key presses, instead of doing all this.

Use a prefix for localStorage keys

Set tasks "done" (or "waiting", "cancelled", "someday-maybe")

Leave something focused after destroying a task

Move focusTaskNameInput and moveCursor into BrowserUI

Destroy tasks

BrowserUI

moveCursor returns whether it was able to or not

Keep the creation timestamp in the DOM

Keep handleKey lean

Keep Log narrowly about log stuff

Persistence

Build and consume Log entries

Writes go through the Log

No empty-string-named tasks

"c" to "Create" tasks