Re: [Vimprobable-users] [PATCH] Move apply_settings to webview_load_committed_cb.

[Hannes S. <ha...@yl...>]

This is quite a complex subject, so let me first describe thec current
behaviour of the patch.

Shorthand definitions:
- state S1: default settings (as defined at compile time plus rc file)
- state S2: site-specific settings for site X as defined in rc file
- setting T1: a custom setting manually set by the user at runtime
  which is not covered by the difference between S1 and S2 (i.e. the
  site specific settings don't change this)
- setting T2: a custom setting manually set by the user at runtime
  which is covered by the difference between S1 and S2 (i.e. the
  site specific settings change this)

Case A:
- start with S1
- go to X -> get S2
- go to another site -> get S1 back

Case B:
- start with S1
- set T1 -> S1+T1
- go to X -> S2+T1
- go to another site -> S1+T1

Case C:
- start with S1
- set T2 -> S1+T2
- go to X -> S2 (T2 overwritten)
- go to another site -> S1+T2 (T2 restored)

Case D:
- start with S1
- go to X -> S2
- set T1 -> S2+T1
- go to another site -> S1+T1 (T1 survives)

Case E:
- start with S1
- go to X -> S2
- set T2 -> S2+T2
- go to another site -> S1 (T2 overridden with respective setting from
  S1)

So if we're talking about user expectations, the only case I believe we
could have a problem is E. Do you agree so far?

Sidenote: If T2 is a boolean setting, there is no problem, because
S1+T2 = S1.

Implementation aside, I'm not sure how this should be ideall handled.
The alternative policy would be to retain T2, i.e. end up with S1+T2,
but that could be non-intuitive as well. So I don't see a clear
advantage over the current behaviour (as described in E). Opinions
welcome!

Hannes