Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Guillaume Munch]

Le 25/11/2015 05:34, Pavel Sanda a écrit :

Guillaume Munch wrote:

Also it looks technically challenging to me to store the state of insets as
user settings. So I am no longer convinced that not storing open/closed
state of insets is feasible and realistic.

No we don't want to store it as user data.

Ok, this now makes more sense that what I had understood initially.

If the state of insets is lost, then we have to revert to a
default state where all the insets are either open or closed. While
for some insets I would no mind to lose the state, losing it for
all insets looks like a dataloss to me. So we cannot afford to
store as user settings things that could cause dataloss.

I did not propose to lose state of all insets,

This was only meant in case we were storing the state as
per-document-per-user data, in that case we must be ready to
lose this information. So I am no longer concerned about that.

but rather keep it
constant across sessions. If you really really want to change some
particular insets then disable git compatiblity mode, commit it and
enable cm again.

I agree that it now makes sense to consider it part of a per-document
setting called "Do not store user preferences in the file"
(store-preferences for short). However, I feel that it still requires
some reflection about giving the user the possibility of force-saving
the open/closed status, and provide feedback about this state. It is a
needed functionality, because otherwise if we start from an empty
document, all the insets are always going to be open, which is obviously
not what we want.

You describe a method for this, above, but to me it sounds like a
cumbersome way to force-record the state of an inset (for instance, it
would force me to check that all other insets are as I want them to be,
which is too much thinking, otherwise the proper method to change the
state of only one inset would be to 1) save, 2) revert, 3) enable
store-preferences, 4) change the state, 5) save, and 6) disable
store-preferences). It also fails to provide feedback on what's the
actual state in the file (notice that this issue is non-existent with
\tracking_changes and others, because then if store-preferences is
false, I would default to false like LibreOffice does for fodt files).
Maybe we can come up with a more satisfactory solution with some
reflection.

Still, a single "git compatibility mode" per-document setting would satisfy
me equally.

You will have my support if you decide to implement it.

Thank you. Since there have been several suggestions to go in this
direction, I may propose such a patch 1) if I find the time, and 2) if
there is no opposing voices in the meanwhile. In a first time it would
only concern the two settings \tracking_changes and \output_changes but
once the file format change is applied, it becomes easier to enrich the
feature.

(I saw nobody deny that \justification ("display justification in LyX
window" or something like that) should be a per-user preference, but
since such a change can be backported without the corresponding file
format change, it is not pressing to implement this before 2.2.0.)

It comes down to whatever is LyX's philosophy: do we want to store user
settings in files? Then let's add a "git mode" per-document setting. Or do

I would say yes.

Thank you for your feedback.


Best wishes,
Guillaume