Automatic post summary causes weird line numbers in code-block

[edelooff]

When leaving Pelican to create post summaries automatically based on the SUMMARY_MAX_LENGTH setting, there is a bad interaction with code-blocks with :linenos: table set:

The amount of code shown depends entirely on the summary max length setting, but the line-numbers table will be as long as the actual code-block in source. This means that for the given article, the code-block ends after three lines, but the line-numbers count up to fitteen.

There are a couple of solutions to this, and perhaps multiple apply:

• For now, I've simply set the linenos to be inline, which removes the problem though copy/paste of code becomes tricky
• Having a per-article summary-max-length could provide for a quick and dirty solution (setting :summary: would cause a lot of duplication for my use-case where I want the first bit of the article in the index)
• Actually checking the number of lines left from the code-block and limiting the number of lines in the line-number cell to that value would clearly be ideal.

[edelooff]

For ease recreating this bug, I've put up a quick post as gist which explains and demonstrates the problem:

• reST post
• raw post content (GitHub doesn't render the code-block)
• Live example of generated output

[justinmayer]

Hi Elmer. Were you able to resolve the problem you reported? If not, what version of Pelican are you using?

If you're not using Pelican 3.4, which we just released two days ago, please upgrade and let us know if your problem persists.

[edelooff]

Hi Justin,

I solved it by working around it, using a plugin so set explicit markers for the summary. However, I'll try again with Pelican 3.4, see what happens without the use of any plugins.

[Scheirle]

This is still present in 3.4.

In my case only the line numbers are shown (but that is irrelevant).

But this behaviour is logical, because all line numbers are "physically" above the first line of code in the generated html.

To fix this we would have to add a special case for tables in the truncate_html_words function.

I assume that this bug can also be reproduced with a normal table:
The row is displayed (because cell 1 of this row is still in the SUMMARY_MAX_LENGTH), but the other cells of the same row are removed. This is technically correct but looks ugly since you already use the full height of the row. (Problem: if we display only a portion of cell 1)

Code tables are special tables with only one row and 2 cells + important line breaks.
Something like this would be necessary:

1. Ignore cell 1
2. x = number of line breaks in cell 2 (which are in the summary)
3. Insert x words form cell 1 in the summary

But I think we should ask us a important question: Do we want tables in the summary?
Normally tables (including code tables) contain complex data and therefore in my opinion should not be automatically summarized by simply removing words.

[leotrs]

Is this still present in 3.6?

[Scheirle]

Is this still present in 3.6?

Yes, https://bernhard.scheirle.de/page/2/ ("Tipue Search - Tag support" article)

[justinmayer]

@Scheirle: I agree that tables are probably not appropriate for summary content. What do you propose we do about that?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your participation and understanding.