Wow… I never thought that getting back in shape with respect to my online activities would be so difficult. While there have been days in the last two weeks where I have had aches and a sore back, there were many more days where I had a bad case of the “done whannas”. For any non-English speakers out there, assume I am saying the words “don’t want to”, but slurring it heavily because… well, I don’t want to.

My vices? Basically, any science fiction long movie, science fiction or fantasy short films, and anime. The fun part is that with the anime, I will watch it multiple times looking for things I may have missed. Some movies are like that too. It can be looking for something interesting (Tenet and Inception) or just because it has an enjoyable story arc. It does not matter.

But sometimes I relax too much when I know that I want to accomplish things like getting further with the PyMarkdown project. That is when it gets in the way. And now that I am feeling better, trying to get back into the habit of working on my open-source projects, as time allows.

While I am just completing some refactoring work that I will talk about next week, I wanted to focus on some interesting issues that I found and fixed. Yes, issues, otherwise known as bugs or features with a bowtie. And yes, my code has issues. I have never denied it. I just try my best to reduce the number of issues in any code that I write by taking a wholistic approach to testing.

Two weeks ago, I wrote about the example that I was working on:

1. abc
   1. def
\t# abc

It did take me a bit to deal with its predecessor:

1. abc
   1. def
    # abc

and then to fix the instance with the tab, but it was a good issue to fix. And it took about a week and a half to fix!

It took me a whole two days to read the example without the tab character properly. To help any readers out there, hopefully the first two lines are simple to parse: an ordered list on line 1 with an ordered sublist on line 2. For some reason, when I read line 3, my mind said that it was another item for the sublist. It took me taking my time and checking against Babelmark to confirm the output:

<ol>
<li>abc
<ol>
<li>def</li>
</ol>
<h1>abc</h1>
</li>
</ol>

That is correct. The Atx Header item on line 3 is not indented enough to continue the sublist, causing it to terminate and the Atx Header is kept within the main list. That was a bit embarrassing when I figured it out. But it was not too embarrassing for me as the parsing was reporting back the same thing that I assumed.

Taking a look at the code at that time, it made sense. Both:

1. abc
   1. def
   # abc

and:

1. abc
   1. def
      # abc

were parsing properly. It was when the text was indented four or five spaces that the parsing failed. In that case, it was continuing the sublist with another list item, and getting things wrong.

It took most of a week’s worth of evenings and spare time on that weekend to figure out all the little issues with it, but I did! The main problem that I had is that when I coded a lot of the list indent logic, I used the indent_level of the two list tokens and the list item token for all operations. In the first case, using the indent_level level was the wrong thing to do. I needed to change the first part of the comparison to the position_marker and its index_number field. That allowed me to properly look to see that the Atx Header starts at column 4, which is greater than or equal to the indent_level for the main list, but is less than the indent_level of the sublist. And as I have done that in multiple places in the code, I am sure I am going to run into that again.

There were of course other little issues with the code. In some cases, I needed to make a small fix, but that small fix broke other parts of the code. It is in those circumstances that I am grateful that I have a deep battery of tests to keep me on the straight and narrow. I cursed at them when I hit them, but I was grateful for them to back me up.

With that block of fixes out of the way, I decided to deal with a couple of bugs that I needed to get to, do some refactoring, and then get ready for a new release. But that is next week. Stay tuned!

Like this post? Share on: TwitterFacebookEmail

Comments

So what do you think? Did I miss something? Is any part unclear? Leave your comments below.


Published

Category

Software Quality

Tags

Stay in Touch