bug#69555: 30.0.50; shr - Preserve indentation when shr-fill-text is nil

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Cc: 69555@debbugs.gnu.org,  rahguzar@zohomail.eu
>> Date: Wed, 06 Mar 2024 00:16:53 +0100
>> 
>> If not, the tentative conclusion would be "shr-fill-text nil gets 4%
>> slower; shr-fill-text t is none the worse for wear; nil still runs
>> circles around t"?
>
> Thanks, I think 4% slowdown is negligible in this case.

ACK.

Re. indentation being done unconditionally…

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The change in behavior is unconditional, AFAIU.  Should we have a
>> separate knob for that?  Perhaps someone out there doesn't want text
>> to be indented when shr-fill-text is nil?
>
> Perhaps; I could look into adding that knob.  FWIW nothing in the
> original feature request (bug#66676) gives me the impression that this
> new option should affect indentation; the stated motivation was:
>
>   > 1) Using `visual-line-mode` for line wrapping. I think this is more
>   > natural for html and makes resizing windows work more nicely.
>
> That's why I interpret the indentation change as a side-effect; curious
> to hear Rahguzar's thoughts though.

… considering Rahguzar's reply (thanks for that, and for the offer to
try the patch 🙏)…

> Another reason I'm not overly fond of adding another knob is figuring
> out what should happen if a user keeps shr-fill-text set to t, but sets
> that hypothetical indentation option to nil.  Should we support that?
> Or should shr-fill-text become a tri-state?  (nil, 'indent-only, t)
>
> I'm open to biting the bullet, but I'd also like to make sure we don't
> sophisticate shr.el further than we want to.

… do we think there is a case for an option to disable indentation then?
Or should we leave that for a future feature request?