Implement escaped ['s and ('s

[bernardosulzbach]

Did not expect this. It's Christmas time.

Thanks, Glen.

You may want to read this. In essence, $$ is the old way, the TeX way, and it conflicts with some LaTeX commands, causing from nothing up to compilation errors (the best way to play is not using it).

Used your source on newest branch, development to alter. (Hope right one, not doing again!)

Yeah, I am familiar enough with Git to move your changes around as I please but starting from development makes it easier for me.

The best workflow right now is:

Clone the repository Checkout the development branch Use git checkout -b descriptive-name-about-my-change to create your own branch After done with your changes git push origin descriptive-name-about-my-change And then open a PR from there

If you want to try this workflow, you could open a PR for adding this instructions to a section of the README to help future contributors.

I will (unless you want to do it) squash your commits into a single one to simplify history, which will make updating your development branch impossible without hard resetting it to much earlier.

The very last commit, just a suggestion, if you want it? bout comments.

Do you want to advocate for it? I am dropping it unless you convince me otherwise. If your editor inserted those then maybe. These "periodical comments" make being consistent very hard (it is very easy to let a chapter or part slip by without their comments.

[bernardosulzbach]

The latest version of your work over mine is at https://github.com/mafagafogigante/formulas/tree/math-escapes

[bernardosulzbach]

You can close your pull request whenever you want, but it makes more sense to let me do it when I am finished merging. Do not delete your branch though, that will make your contributions inaccessible to me.

Notice that any changes you make to the published branch after opening the PR will be reflected here, so do not start working on two different things in the same branch, it will pollute the pull request, instead, go one branch by feature. Branches are really cheap with git.

About number of branches, anything between 1 and 1000 should be fine, the problem is that having too many will pollute your repository and it makes it harder to find the one you are looking for.

Ideally you would have something like

master (updated from my master and nothing more)
development (updated from my development and nothing more)
smaller-margins (starting from either master or development should be fine)
contributing-guidelines (idem)
...

You are also welcome to propose changes to existing text and to further write on my notebook, this is meant to be a collaborative effort. You cannot, however, change the license or pressure me to accept your changes, if they are justified, they will be accepted.

Numbering equations? I don't care. Trying not to be rude, but I mean, whatever. Want to number them? Do it. I just remind you that a document must be consistent in style from beginning to end, so if you are going for numbering, make it universal. I understand that it will make our lives easier so we can open an issue such as "Equation 14 shouldn't have a plus-minus sign". They help us name things, which is great.

About number of pages and margins, I personally like big margins, but I've used smaller ones in the past. You are free to propose changes if you think that smaller margins would make it better. You can always - and I incentive you to do so - create an issue to discuss a modification before writing it (so you don't have to implement something I will not use).

I may write a note (if I haven't already) asking people not to print this file. I don't like wasting paper. Paper does not even give you automated text searching! You can use some PDF readers to sketch on the margins if you want and erase it later.

About

Close #8

However, using a "Close #N" in a commit message, for instance, will close the issue #N whenever I merge that commit into my master branch. Cool, right?