Le 11/01/2016 10:14, Jean-Marc Lasgouttes a écrit :
Le 11/01/2016 11:07, Pavel Sanda a écrit :
Kornel Benko wrote:
This all is getting more and more confusing. Too complicated (at
least for me)
You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.
This is an issue I had too. Freezing settings seems more interesting
that setting them to false. It is more work too, maybe too much work
actually.
Dear Pavel and Jean-Marc,
I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.
I see several drawbacks to "freezing":
* With "freezing", the user must know what settings are going to be
affected. This means a heavier description in the user interface, and a
feature less easy to understand.
* This is only relevant for scenarios where we want the same setting on
opening for all collaborators (or where one user
knows-better-than-everybody-else). As soon as there is no agreement, we
are back to the situation that we were trying to solve.
* The use-case of "choosing a setting for everybody else" overlaps with
the current behaviour provided by "\save_user_preferences true".
* On the other hand, it does not address the need for having the
settings entirely independent between collaborators.
Thus the per-user approach encompasses a wider set of use-cases,
overlaps less with the current behaviour, and is simpler to explain and
understand. Moreover, storing always the same value "false" is similar
to what is done in LibreOffice's corresponding feature (saving to the
.fodt format).
Guillaume
