Requirements for a minimal viable TODO

# Minimal Viable TODO

The TODO list is an editable document in MarkDown.

1. The system uses a CodeMirror instance. Each line is an item.

2. It persists data to local storage AND to the server's .data directory.

3. It uses Markdown as a representation

4. Markdown heading lines (starting with one or more #) are section markers. So # Next is the next group. # Projects is the project group. Projects start with ##. Subprojects with ###

5. When I leave a line the system turns the line from Markdown to HTML Entering a line reverses the process.

7. When I leave a line, any line with a # or @ annotation is moved to the matching section. Top or bottom of section to be decided later.

8. The annotation #done overrides all other # annotations, and moves the item to the end of the relevant section. #done lines are rendered with a .task_done style, which is a strikethrough.

9. Ctrl-up/Down are used to move lines up and down

10. Ctrl-K selects the current word (if nothing is selected) or uses the current selection, and wraps it in [] and pastes the current clipboard contents wrapped in (). This is the markdown link syntax.

11. Add a RESTFUL API that will let me read the list or push it to a remote site.

12. Push the system to `glitch` which will give me a project that I can work on, online.

# Ideas for next phase

Use the CodeMirror `marktext` API and code folding API to hide/show regions of the document.

By default, regions are unfolded when the cursor enters them; are folded when the cursor moves out.

Convert atomic edits to Redux Actions.

VS Code multi-process debugging

VS Code is cool!

I set up a project here on Github to demonstrate debugging two processes— a parent process and a child.

The parent launch configuration looks like this:

 {
            "type": "node",
            "request": "launch",
            "name": "Parent",
            "program": "${workspaceRoot}/parent.js",
            "args": [],
            "cwd": "${workspaceRoot}"
            // ,"port": 5858
            ,"protocol": "auto"

        }

Note that the port:5858 line is commented out. If it’s included, everything works, but later, when we launch both parent and child together, there are problems.

Parent code:

console.log("Parent running")
const cp = require('child_process');

const child = cp.fork(`${__dirname}/child.js`,{
 //force the debug port to the one in the launch config
 execArgv: ["--debug=5859"]
 ,silent: true
//  ,stdio: 'ipc'
}
);

//Child data does not go to console with VS Code
//So do this.
child.stdout.on("data", (m) => console.log(m.toString()));

const sender = () => {
    child.send({ hello: 'world' });
}

child.on('message', (m) => {
  console.log('PARENT got message:', m);
  sender()
});

The parent has to pass debug=5859 to the child, and the Child launch configuration has to have that port set:

  {
        "name": "Child",
        "type": "node",
        "request": "attach",
        "port": 5859,
        "address": "localhost",
        "restart": false,
        "sourceMaps": false,
        "outFiles": [],
        "localRoot": "${workspaceRoot}",
        "remoteRoot": null,
        "protocol": "legacy"
    }

The child looks like this:

console.log("Child started\nu");
console.log(process.argv)

sender = () => {
    process.send({ foo: 'bar' });
}

process.on('message', (m) => {
  console.log('CHILD got message:', m);
  sender()

});
//start by sending a message
sender();

The README.md file explains how to use the project

VS Code Child Process Debug

This is a VS code project that lets you open a debugger on a parent process and a child at the same time.

It shows several ways to connect:

1. Connecting to one process at a time in debugger
2. Connecting to both together in debugger
3. Connecting to a parent started in a console

Connecting to one process at a time in debugger

1. Switch to the debug view
2. Set a breakpoint in parent.js in the line that reads:
   console.log('PARENT got message:', m);
3. Set a breakpoint in child.js in the line that reads:
   console.log('CHILD got message:', m);
4. Select Program as the launch configuration
5. Start the debugger by clicking on the green arrow key or F5. A debug widget
   
   will appear and the debugger will stop in parent.js and display the file in an editor pane. You’ll get output in the console that looks like this:

Debugging with inspector protocol because Node v6.10.0 was detected.
node --inspect=SOME PORT --debug-brk parent.js 
Debugger listening on port 5858.
Warning: This is an experimental feature and could change at any time.
Debugger attached.
Parent running
Child started
[ '/home/mwolf/tools/node-v6.10.0-linux-x64/bin/node',
  '/home/mwolf/tools/junk/child.js' ]
*******************

Like this one

1. Choose Child in the launch configuration, and press the green arrow key to attach to the child.

Note: in this case F5 will not attach to the child, but cause the already running parent to continue and stop at the breakpoint again.

1. The debug widget will now have a a drop-down list and let you switch between the parent (launch) process or to the child. You can also disconnect from one or the other
2. If you press the green arrow in the debugger widget, or F5, the program will run to the next breakpoint—which by design is in the other process, display the code and stop there. Pressing F5 again moves it back.
3. If you have two tab sets open and move one file to each set, then you’ll see it toggle back and forth as you hit successive breakpoints.

Connecting to both together

1. Select the Program/Child launch configuration.
2. Press F5 of click on the green arrow.
3. The debugger will stop in parent.js and both

Disconnecting and reconnecting

If you disconnect from the parent, then the child disconnects as well. But if you disconnect from the child, you can reconnect using the child launch configuration

​