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

[Rahguzar]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Lars, anybody else?  Any comments to these changes?
>
> As an occasional user of shr (mainly when viewing HTML parts in Gnus)
> who frequently messes with window width and face height, I'm very much
> interested in better visual-line-mode integration.  Also intrigued by
> outline-mode support.  So closely following this thread, and
> enthusiastically thanking Rahguzar for tackling this 👏
>
> 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.

Rahguzar