Craig's Work

[polyglot-jones]

Hi All,

I cancelled the 2 PR's that were putting me into rebase hell and starting over. From now on, I will only be submitting one incremental PR at a time.
However, if you want a preview of all of my work to date, it can be found at: https://github.com/polyglot-jones/ST3-Asciidoctor/tree/wip_all (as in "All Work In Progress). Furthermore, if you see any issues with my WIP and want to address them before I ever submit a PR, by all means open a ticket on my branch (https://github.com/polyglot-jones/ST3-Asciidoctor/issues) -- or, for non-specific comments, discuss them below.

// Craig

[tajmone]

I cancelled the 2 PR's that were putting me into rebase hell and starting over.

Yes, I noticed and also added my comment on what I think might be the problem at the source of this and a possible viable solution.

When you're facing a rebase hell in a PR branch, it's usually a sign that things aren't quite right, and that merging it as it is might jeopardize the repository history linearity (which is bad).

See my comment on PR #20 about using git checkout to integrate changes into the work area from branches coming from other remotes.

From now on, I will only be submitting one incremental PR at a time.

That's always the best policy IMO, especially if we'll end up trying to join the efforts of different forks into a new package repository — having a clean history of commits dealing each with a feature at the time would simplify tracking changes via blame and cherry picking to create a new codebase integrating changes from all parties.

However, if you want a preview of all of my work to date, it can be found at: https://github.com/polyglot-jones/ST3-Asciidoctor/tree/wip_all (as in "All Work In Progress). Furthermore, if you see any issues with my WIP and want to address them before I ever submit a PR, by all means open a ticket on my branch (https://github.com/polyglot-jones/ST3-Asciidoctor/issues) -- or, for non-specific comments, discuss them below.

That's an excellent idea! I could also pick selected changes/features from your repository and add them here crediting you, as well as creating PRs on your fork (I'll first discuss the latter with you, so we can coordinate efforts better).

When I manage to find some spare free time (which is kind of a huge bet, right now) I'd like to look again into implementing handling of tables — even it's just a "dumb matching" of table block delimiters start and end, because column delimiters are one of the main cause of syntax breakage (due the various chars like ^, which are parsed as if they were formatting delimiters). So it would be better to have tables which are not syntax highlighted inside, than having broken docs that are not able to index sections, etc.

Then implementing correct highlighting of the columns delimiters shouldn't be too hard, although there's a limit to how accurately ADoc tables can be handed, due to all the different table types, nested tables, custom delimiters chars, etc. But covering the base use cases and prevent doc breakage would be a good start though.

[polyglot-jones]

look again into implementing handling of tables

OK. Added to my personal to-do list.