Need a new fix and test for page variable .Truncated

[anthonyfok]

Previously, in Hugo v0.12, the formerly undocumented .Truncated may return true even when the summary contains the entire content, i.e. not truncated, for Hugo's automatically generated summary (i.e. no user <!--more--> tag). The reason is due to whitespaces, as seen in the following example:

helpers.TruncateWordsToWholeSentence() gives:

Nitro Quick and easy performance analyzer library for Go. Overview Nitro is a quick and easy performance analyzer library for Go. It is useful for comparing A/B against different drafts of functions or different functions. Implementing Nitro Using Nitro is simple. First, use go get to install the latest version of the library. $ go get github.com/spf13/nitro Next, include nitro in your application.

whereas strings.TrimSpace() gives:

Nitro  Quick and easy performance analyzer library for Go.
  Overview  Nitro is a quick and easy performance analyzer library for Go. It is useful for comparing A/B against different drafts of functions or different functions.
  Implementing Nitro  Using Nitro is simple. First, use go get to install the latest version of the library.
  $ go get github.com/spf13/nitro   Next, include nitro in your application.

I tried to remedy that situation with the following one-line fix:

commit 02da495
Author: Anthony Fok foka@debian.org
Date: Tue Jan 20 15:50:32 2015 -0700

Fix string comparison for .Truncated page variable

Instead of strings.TrimSpace(), use strings.Join(strings.Fields(s), " ")
to collapse all whitespaces into single spaces, in order to match the
behaviour of helpers.TruncateWordsToWholeSentence(),
in order to detect non-truncated content correctly.

Unfortunately, strings.Join(strings.Fields(s), " ") turns out to be a rather expensive operation that "adds about 10% to the processing time" as @bep has discovered (Good catch!) while optimizing performance for the upcoming Hugo v0.13 release, so @bep had to disable it for the time being: f8704c1#diff-204b5518c5299155dd3b72a4299751f9L181

I agree with @bep's assessment: "if really needed, should be solved differently."
There should be a more efficient way to determine whether the content were truncated. Besides, few people uses the .Truncated, and the worst it could happen is that there would be "Read More..." links appearing even for very short posts (i.e. no big deal). So, there is no urgency to fix it in v0.13 especially when we want to make a release ASAP.

Hence this reminder to deal with this issue in the future, maybe for v0.14 or v0.15. ;-)

[anthonyfok]

Amazing, @bep! And such a fast response too! Thank you for your great work!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.