bug#66676: 29.1; Should some aspects of shr rendering be configurable

[Kévin Le Gouguec]

Rahguzar <rahguzar@zohomail.eu> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> Don't know if I have anything insightful to say re. the patches.  Idly
>> wondering if '(null shr-fill-text) ⇒ (visual-line-mode)' is the right
>> control flow; e.g. maybe
>>
>>   (a) shr-fill-text could be set to 'visual as a more explicit hint for
>>   major modes, or
>>
>>   (b) major modes should grow new user options: e.g. eww-wrap-method ∈
>>   {fill, visual}; 'visual would tell modes to set shr-fill-text to nil &
>>   enable visual-line-mode.
>>
>> There are already plenty of user knobs at the shr level though, so maybe
>> no need to overthink this.
>
> I don't quite see the need of a user option to turn on a minor mode. It
> seems better to take the value of `shr-fill-text` as a hint and turn on
> the `visual-line-mode` as I have done. I don't think anyone want to see
> html rendered without some kind of reflowing. And if they do, they can
> turn off the mode in `eww-after-render-hook`. Otherwise, we can also not
> do anything and let the users add `visual-line-mode` to
> `eww-after-render-hook`. To me hooks rather than dedicated user options
> are the correct way to manage minor modes.

Gotcha.  Not sure why I have such a knee-jerk response to automating
visual-line-mode activation.

OT1H part of me likes your idea of not doing anything and letting users
add visual-line-mode to eww-after-render-hook: it's explicit, it's less
work for folks who would prefer to keep it off;
OTOH, can't quite picture anyone actually preferring that.  I guess by
default, truncate-lines being nil, they would get some sort of
"reflowing"…

Tentative bottomline: it's fine as-is really 👍 The knobs are all there;
I don't have an alternative that I strongly believe in.