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

[Pavel Sanda]

Guillaume Munch wrote:
> We could leave this aside for the moment no? Are you afraid that it would 
> cast the situation in stone and somebody who comes up with a good solution 
> won't be able to implement it anymore?

I was just sharing my thoughts.
Pavel

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

[Guillaume Munch]

Le 30/11/2015 01:15, Pavel Sanda a écrit :

Guillaume Munch wrote:

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


I agree it is cumbersome, my reasoning was that I would rather impose this
complexity on user who is using git & CT than complicating anything for user
who just uses CT.



We could leave this aside for the moment no? Are you afraid that it 
would cast the situation in stone and somebody who comes up with a good 
solution won't be able to implement it anymore?


By the way, I forgot the step 1.5) "do a dummy modification" between 1) 
"save" and 2) "revert", so it's really a 7-step process.

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

[Pavel Sanda]

Guillaume Munch wrote:
> 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

I agree it is cumbersome, my reasoning was that I would rather impose this
complexity on user who is using git & CT than complicating anything for user
who just uses CT.

Pavel

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

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

[Pavel Sanda]

Guillaume Munch wrote:
>> 3. General preference (not sure if document or user) for ignoring non 
>> essential
>> changes, which disturbs version control flow. Similar to 1. but it
>> would encompass e.g. CT on/off, output_changes, GUI justification.
>> I have another candidate here as well - not storing opening/closing 
>> insets.
>
> So essentially a single setting for all user-like document settings.
>
> You had convinced me with your "open/closed inset" point that actually LyX 
> records more than I previously thought the current state of user 
> preferences inside files, while my point was that it seems to me that this 
> less LyX's philosophy than e.g. LibreOffice's. I also like the idea that 
> storing the open/closed state of insets may not always be what we want.
>
> But I thought about it more. 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, 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. 

> 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.

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

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

> 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.

Pavel

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

[Guillaume Munch]

Le 17/11/2015 21:36, Georg Baum a écrit :

Guillaume Munch wrote:


Le 08/11/2015 16:16, Georg Baum a écrit :


If I understood Vincent correctly then it would not be a file format
change IMHO:

As I understood it, he referred to the suggestion that the "track
changes" button would be decoupled from \track_changes in the file:
\track_changes would set the state of the button on opening a document,
but changing the change tracking status would not write back anything to
the file.


What I understood as well, up to minor points (if \track_changes is set
to false, then we can fall back to the per-user, per-document setting,
because I haven't heard people on the list make a use case out of
forcing CT to be disabled on opening...).


This introduces some unsymmetry, but you are right, I don't know of a use
case for forcing CT off either.


There
would be a separate lfun for setting the default in the file.


A minor technical question: there are no LFUN for document settings
usually right? You are suggesting a new LFUN for convenience?


There are not many, but some exist (e.g. textclass-apply). I do not know why
there are so few lfuns for document settings, but to me it looks natural to
have one.


In this case, the file syntax would be kept, but the meaning of
\track_changes would change a bit.


I made it a file format change because I imagined that we would have to
reset the state of the setting while converting, but good to know that
you are ready to obviate this step.



After thinking a bit about this
suggestion I believe it could be a good compromise for everybody, and I
would not treat this as a file format change.


Either that, or add a git mode, in which case it would be good to add
the setting before 2.2, even if it does not encompass everything right
from the start. Either suit me; it's a matter of LyX's philosophy as per
my other message.


I am not sure whether a git mode would be desirable. I believe that all
issues observed so far can also be a problem without VCS, so I think solving
them on a case by case basis helps more users.


To be clearer, I did not literally mean a "git mode". Rather, a "do not
write user preferences to file" per-document setting similarly to
LibreOffice. I would rather avoid a catch-all option whose effect is
unclear to the user.




Ping me if you finally find a consensus on whether there is a consensus :)


Actually I have no idea;-( I simply told my opinion.



The discussion seems to orient towards adding new per-document settings
to avoid writing user preferences to files. The questions is whether we
want one option for all preferences (a "do not write user preferences to
file" option as above), or just make the fields \tracking_changes, etc.,
independent from the current settings.

I have already voiced that either is fine by me. I would also like to
point out that one possibility requires a (trivial) file format change,
the other not. Therefore if we wait until after 2.2 release I imagine
that there is going to be more pressure towards the latter solution. It
is better if members of this list voice their opinion now if they prefer
the global per-document setting.

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

[Richard Heck]

On 11/22/2015 07:29 AM, Guillaume Munch wrote:
> Le 17/11/2015 21:36, Georg Baum a écrit :
>> Guillaume Munch wrote:
>>
>>> Le 08/11/2015 16:16, Georg Baum a écrit :

 If I understood Vincent correctly then it would not be a file format
 change IMHO:

 As I understood it, he referred to the suggestion that the "track
 changes" button would be decoupled from \track_changes in the file:
 \track_changes would set the state of the button on opening a
 document,
 but changing the change tracking status would not write back
 anything to
 the file.
>>>
>>> What I understood as well, up to minor points (if \track_changes is set
>>> to false, then we can fall back to the per-user, per-document setting,
>>> because I haven't heard people on the list make a use case out of
>>> forcing CT to be disabled on opening...).
>>
>> This introduces some unsymmetry, but you are right, I don't know of a
>> use
>> case for forcing CT off either.
>>
 There
 would be a separate lfun for setting the default in the file.
>>>
>>> A minor technical question: there are no LFUN for document settings
>>> usually right? You are suggesting a new LFUN for convenience?
>>
>> There are not many, but some exist (e.g. textclass-apply). I do not
>> know why
>> there are so few lfuns for document settings, but to me it looks
>> natural to
>> have one.
>>
 In this case, the file syntax would be kept, but the meaning of
 \track_changes would change a bit.
>>>
>>> I made it a file format change because I imagined that we would have to
>>> reset the state of the setting while converting, but good to know that
>>> you are ready to obviate this step.
>>>
>>>
 After thinking a bit about this
 suggestion I believe it could be a good compromise for everybody,
 and I
 would not treat this as a file format change.
>>>
>>> Either that, or add a git mode, in which case it would be good to add
>>> the setting before 2.2, even if it does not encompass everything right
>>> from the start. Either suit me; it's a matter of LyX's philosophy as
>>> per
>>> my other message.
>>
>> I am not sure whether a git mode would be desirable. I believe that all
>> issues observed so far can also be a problem without VCS, so I think
>> solving
>> them on a case by case basis helps more users.
>
> To be clearer, I did not literally mean a "git mode". Rather, a "do not
> write user preferences to file" per-document setting similarly to
> LibreOffice. I would rather avoid a catch-all option whose effect is
> unclear to the user.
>
>>
>>> Ping me if you finally find a consensus on whether there is a
>>> consensus :)
>>
>> Actually I have no idea;-( I simply told my opinion.
>>
>
> The discussion seems to orient towards adding new per-document settings
> to avoid writing user preferences to files. The questions is whether we
> want one option for all preferences (a "do not write user preferences to
> file" option as above), or just make the fields \tracking_changes, etc.,
> independent from the current settings.
>
> I have already voiced that either is fine by me. I would also like to
> point out that one possibility requires a (trivial) file format change,
> the other not. Therefore if we wait until after 2.2 release I imagine
> that there is going to be more pressure towards the latter solution. It
> is better if members of this list voice their opinion now if they prefer
> the global per-document setting.

I'm not sure about this. Changes to preference file format do require a
format
change for the preference files, accounted for by the prefs2prefs
script. Like
layout2layout, it is forward only.

Richard

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

[Guillaume Munch]

Le 22/11/2015 18:18, Richard Heck a écrit :

On 11/22/2015 07:29 AM, Guillaume Munch wrote:

Le 17/11/2015 21:36, Georg Baum a écrit :

Guillaume Munch wrote:


Le 08/11/2015 16:16, Georg Baum a écrit :


If I understood Vincent correctly then it would not be a file format
change IMHO:

As I understood it, he referred to the suggestion that the "track
changes" button would be decoupled from \track_changes in the file:
\track_changes would set the state of the button on opening a
document,
but changing the change tracking status would not write back
anything to
the file.


What I understood as well, up to minor points (if \track_changes is set
to false, then we can fall back to the per-user, per-document setting,
because I haven't heard people on the list make a use case out of
forcing CT to be disabled on opening...).


This introduces some unsymmetry, but you are right, I don't know of a
use
case for forcing CT off either.


There
would be a separate lfun for setting the default in the file.


A minor technical question: there are no LFUN for document settings
usually right? You are suggesting a new LFUN for convenience?


There are not many, but some exist (e.g. textclass-apply). I do not
know why
there are so few lfuns for document settings, but to me it looks
natural to
have one.


In this case, the file syntax would be kept, but the meaning of
\track_changes would change a bit.


I made it a file format change because I imagined that we would have to
reset the state of the setting while converting, but good to know that
you are ready to obviate this step.



After thinking a bit about this
suggestion I believe it could be a good compromise for everybody,
and I
would not treat this as a file format change.


Either that, or add a git mode, in which case it would be good to add
the setting before 2.2, even if it does not encompass everything right
from the start. Either suit me; it's a matter of LyX's philosophy as
per
my other message.


I am not sure whether a git mode would be desirable. I believe that all
issues observed so far can also be a problem without VCS, so I think
solving
them on a case by case basis helps more users.


To be clearer, I did not literally mean a "git mode". Rather, a "do not
write user preferences to file" per-document setting similarly to
LibreOffice. I would rather avoid a catch-all option whose effect is
unclear to the user.




Ping me if you finally find a consensus on whether there is a
consensus :)


Actually I have no idea;-( I simply told my opinion.



The discussion seems to orient towards adding new per-document settings
to avoid writing user preferences to files. The questions is whether we
want one option for all preferences (a "do not write user preferences to
file" option as above), or just make the fields \tracking_changes, etc.,
independent from the current settings.

I have already voiced that either is fine by me. I would also like to
point out that one possibility requires a (trivial) file format change,
the other not. Therefore if we wait until after 2.2 release I imagine
that there is going to be more pressure towards the latter solution. It
is better if members of this list voice their opinion now if they prefer
the global per-document setting.


I'm not sure about this. Changes to preference file format do require a
format
change for the preference files, accounted for by the prefs2prefs
script. Like
layout2layout, it is forward only.



I am not sure we understood each other. It is only question of new
per-document settings, no new per-user setting. (Also I understand that
the per-user-per-document settings mentioned by Vincent use a different
mechanism if those are needed.)

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

[Georg Baum]

Guillaume Munch wrote:

> Le 08/11/2015 16:16, Georg Baum a écrit :
>>
>> If I understood Vincent correctly then it would not be a file format
>> change IMHO:
>>
>> As I understood it, he referred to the suggestion that the "track
>> changes" button would be decoupled from \track_changes in the file:
>> \track_changes would set the state of the button on opening a document,
>> but changing the change tracking status would not write back anything to
>> the file.
> 
> What I understood as well, up to minor points (if \track_changes is set
> to false, then we can fall back to the per-user, per-document setting,
> because I haven't heard people on the list make a use case out of
> forcing CT to be disabled on opening...).

This introduces some unsymmetry, but you are right, I don't know of a use 
case for forcing CT off either.

>> There
>> would be a separate lfun for setting the default in the file.
> 
> A minor technical question: there are no LFUN for document settings
> usually right? You are suggesting a new LFUN for convenience?

There are not many, but some exist (e.g. textclass-apply). I do not know why 
there are so few lfuns for document settings, but to me it looks natural to 
have one.

>> In this case, the file syntax would be kept, but the meaning of
>> \track_changes would change a bit.
> 
> I made it a file format change because I imagined that we would have to
> reset the state of the setting while converting, but good to know that
> you are ready to obviate this step.
> 
> 
>> After thinking a bit about this
>> suggestion I believe it could be a good compromise for everybody, and I
>> would not treat this as a file format change.
> 
> Either that, or add a git mode, in which case it would be good to add
> the setting before 2.2, even if it does not encompass everything right
> from the start. Either suit me; it's a matter of LyX's philosophy as per
> my other message.

I am not sure whether a git mode would be desirable. I believe that all 
issues observed so far can also be a problem without VCS, so I think solving 
them on a case by case basis helps more users.

> Ping me if you finally find a consensus on whether there is a consensus :)

Actually I have no idea;-( I simply told my opinion.


Georg

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

[Guillaume Munch]

Le 07/11/2015 21:18, Pavel Sanda a écrit :

Guillaume Munch wrote:

Have a new checkbox in document settings labelled "Open with change
tracking enabled". Then the current state of change tracking is made
independent from this checkbox; only, if the box is checked then it will
do as advertised by the label. Otherwise, the per-user, per-session
setting is restored.

This seems to fit better than the current situation what I understand of
Pavel and other people's use case for change tracking. Indeed, even in


My summary is quite different. The current situation seems to be more in
tune with what most people expect and what other offices are doing.



Hi Pavel,

Thank you for making these suggestions. I see that you suggest small 
variations on adding a new setting, so I am happy to see some convergence.



That said I understand your pain and agree that it sucks for version control
usecase. My take on that would be one of those directions:

1. User preference for ignoring CT toggling changes during the session.
The CT on/off status would be saved in the same way as it was opened
no matter whether the user changed it during editing.


So a "Save change tracking within document" per-user checkbox. The 
difference with a suggestion à la Vincent are that the current status of 
change tracking is saved, and it is per-user instead of per-document.


I had thought about it, and it makes more sense to me as a per-document 
setting than as a per-user setting to me. Then, if it's per-document, I 
do not see the need to add an additional indirection via the current CT 
state, so we can let the checkbox directly determine the state on 
opening. This is why I was convinced by the "Open with change tracking 
enabled" checkbox.



2. Some form of turn on/off permanently vs intermittently, both in menu
or it could be tristate. (Code-wise it might be similar to 1. I am
thinking more how it appears in GUI to the user.)


Well the idea of a tri-state button was what I elaborated with the "CT 
lock" suggestion (up to minor differences). I imagined a "lock" button 
next to the current button and activating the lock activates the usual 
button at the same time, so in practice it was really a tri-state 
setting. But then I needed a way to make the interface worthwhile and 
intuitive so I suggested that deactivating the lock shows a confirmation 
prompt to the user, but then it was too much "bells and whistles" 
according to replies. Logic and file-wise, yes it's very similar to the 
previous one and it would reuse \tracking_changes as well (as I had 
suggested it, we would also have needed to record who activated the lock 
but this was inessential).



3. General preference (not sure if document or user) for ignoring non essential
changes, which disturbs version control flow. Similar to 1. but it
would encompass e.g. CT on/off, output_changes, GUI justification.
I have another candidate here as well - not storing opening/closing insets.


So essentially a single setting for all user-like document settings.

You had convinced me with your "open/closed inset" point that actually 
LyX records more than I previously thought the current state of user 
preferences inside files, while my point was that it seems to me that 
this less LyX's philosophy than e.g. LibreOffice's. I also like the idea 
that storing the open/closed state of insets may not always be what we want.


But I thought about it more. 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.


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.


Still, a single "git compatibility mode" per-document setting would 
satisfy me equally. But, would it really encompass more than the two 
change-tracking settings? (\justification seems a different case to me 
as I am still convinced that it should be purely per-user.)


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 we want user settings never to be stored within files? Then make CT 
per-user-per-document, and add a "Open with CT enabled" per-document 
setting.




Guillaume

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

[Guillaume Munch]

Le 08/11/2015 16:16, Georg Baum a écrit :

Richard Heck wrote:


On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:


Is it really a file format change? If we do not change the physical
appearance of the file format, and if we do not change the document
output of a certain file, is it then still forbidden to change in a
minor release?



Yes, it is a file format change. It means (say) that 2.2.2 files throw
errors when they are read with 2.2.1.


If I understood Vincent correctly then it would not be a file format change
IMHO:

As I understood it, he referred to the suggestion that the "track changes"
button would be decoupled from \track_changes in the file: \track_changes
would set the state of the button on opening a document, but changing the
change tracking status would not write back anything to the file.


What I understood as well, up to minor points (if \track_changes is set 
to false, then we can fall back to the per-user, per-document setting, 
because I haven't heard people on the list make a use case out of 
forcing CT to be disabled on opening...).



There
would be a separate lfun for setting the default in the file.


A minor technical question: there are no LFUN for document settings 
usually right? You are suggesting a new LFUN for convenience?




In this case, the file syntax would be kept, but the meaning of
\track_changes would change a bit.


I made it a file format change because I imagined that we would have to 
reset the state of the setting while converting, but good to know that 
you are ready to obviate this step.




After thinking a bit about this
suggestion I believe it could be a good compromise for everybody, and I
would not treat this as a file format change.


Either that, or add a git mode, in which case it would be good to add 
the setting before 2.2, even if it does not encompass everything right 
from the start. Either suit me; it's a matter of LyX's philosophy as per 
my other message.


Ping me if you finally find a consensus on whether there is a consensus :)


Guillaume

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

[Richard Heck]

On 11/08/2015 11:16 AM, Georg Baum wrote:

Richard Heck wrote:


On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:

Is it really a file format change? If we do not change the physical
appearance of the file format, and if we do not change the document
output of a certain file, is it then still forbidden to change in a
minor release?


Yes, it is a file format change. It means (say) that 2.2.2 files throw
errors when they are read with 2.2.1.

If I understood Vincent correctly then it would not be a file format change
IMHO:

As I understood it, he referred to the suggestion that the "track changes" 
button would be decoupled from \track_changes in the file: \track_changes would set the 
state of the button on opening a document, but changing the change tracking status would 
not write back anything to the file. There would be a separate lfun for setting the 
default in the file.

In this case, the file syntax would be kept, but the meaning of \track_changes 
would change a bit. After thinking a bit about this suggestion I believe it 
could be a good compromise for everybody, and I would not treat this as a file 
format change.


Yes, sorry, I may have misunderstood.

Richard

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

[Georg Baum]

Richard Heck wrote:

> On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:
>>
>> Is it really a file format change? If we do not change the physical
>> appearance of the file format, and if we do not change the document
>> output of a certain file, is it then still forbidden to change in a
>> minor release?
>>
> 
> Yes, it is a file format change. It means (say) that 2.2.2 files throw
> errors when they are read with 2.2.1.

If I understood Vincent correctly then it would not be a file format change 
IMHO:

As I understood it, he referred to the suggestion that the "track changes" 
button would be decoupled from \track_changes in the file: \track_changes 
would set the state of the button on opening a document, but changing the 
change tracking status would not write back anything to the file. There 
would be a separate lfun for setting the default in the file.

In this case, the file syntax would be kept, but the meaning of 
\track_changes would change a bit. After thinking a bit about this 
suggestion I believe it could be a good compromise for everybody, and I 
would not treat this as a file format change.


Georg

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

[Guenter Milde]

On 2015-11-07, Pavel Sanda wrote:
> Guillaume Munch wrote:
>> Have a new checkbox in document settings labelled "Open with change
>> tracking enabled". Then the current state of change tracking is made
>> independent from this checkbox; only, if the box is checked then it will
>> do as advertised by the label. Otherwise, the per-user, per-session
>> setting is restored.

>> This seems to fit better than the current situation what I understand of
>> Pavel and other people's use case for change tracking. Indeed, even in

> My summary is quite different. The current situation seems to be more in 
> tune with what most people expect and what other offices are doing.

> That said I understand your pain and agree that it sucks for version control
> usecase. My take on that would be one of those directions:

> 1. User preference for ignoring CT toggling changes during the session.
>The CT on/off status would be saved in the same way as it was opened
>no matter whether the user changed it during editing.
> 2. Some form of turn on/off permanently vs intermittently, both in menu
>or it could be tristate. (Code-wise it might be similar to 1. I am
>thinking more how it appears in GUI to the user.)
> 3. General preference (not sure if document or user) for ignoring non 
> essential
>changes, which disturbs version control flow. Similar to 1. but it
>would encompass e.g. CT on/off, output_changes, GUI justification.
>I have another candidate here as well - not storing opening/closing insets.

I like 3 even for my local personal git VC - no change when opening/closing
insets.

Günter

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

[Jean-Marc Lasgouttes]

Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch  a écrit :

>Yes, I fully understand this point and I agree that a decision has to
>be taken somehow quickly, this is why I brought the subject to the
>list.
>We are in the process of releasing alpha and this discussion is not
>delaying alpha, so I believe it comes just in time for 2.2 given the
>annoyance of the bug and the fact that it incurs a file format change.

Considering that this situation has been stable for the last 12 years, we could 
also consider that the urgency of changing things just before a release is low, 
especially since  the agreement on what we should do is weak.

Personally, I would prefer to keep it as it is but, as Pavel said, have a 
setting for git-friendly workflow. This requires a bit of design, though.

JMarc

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

[Richard Heck]

On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:


> Democracy is not the point IMHO: The point is not to further delay the
> release. Implementing a small and safe file format change where 
everybody
> agrees that it is useful does not produce a significant delay. 
Discussing a
> controversal change where no easy solution is in sight has the 
potential of
> delaying the release (at least if the possibility of implementing 
the change
> before the release is seriously considered). Therefore I think that 
it is

> not the right time right now to have this discussion.
>

Is it really a file format change? If we do not change the physical 
appearance of the file format, and if we do not change the document 
output of a certain file, is it then still forbidden to change in a 
minor release?




Yes, it is a file format change. It means (say) that 2.2.2 files throw 
errors when they are read with 2.2.1.


Richard

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

[Pavel Sanda]

Guillaume Munch wrote:
> Have a new checkbox in document settings labelled "Open with change
> tracking enabled". Then the current state of change tracking is made
> independent from this checkbox; only, if the box is checked then it will
> do as advertised by the label. Otherwise, the per-user, per-session
> setting is restored.
>
> This seems to fit better than the current situation what I understand of
> Pavel and other people's use case for change tracking. Indeed, even in

My summary is quite different. The current situation seems to be more in 
tune with what most people expect and what other offices are doing.

That said I understand your pain and agree that it sucks for version control
usecase. My take on that would be one of those directions:

1. User preference for ignoring CT toggling changes during the session.
   The CT on/off status would be saved in the same way as it was opened
   no matter whether the user changed it during editing.
2. Some form of turn on/off permanently vs intermittently, both in menu
   or it could be tristate. (Code-wise it might be similar to 1. I am
   thinking more how it appears in GUI to the user.)
3. General preference (not sure if document or user) for ignoring non essential
   changes, which disturbs version control flow. Similar to 1. but it
   would encompass e.g. CT on/off, output_changes, GUI justification.
   I have another candidate here as well - not storing opening/closing insets.

Pavel

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

[Richard Heck]

On 11/07/2015 04:46 PM, Jean-Marc Lasgouttes wrote:


Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch  a écrit :


Yes, I fully understand this point and I agree that a decision has to
be taken somehow quickly, this is why I brought the subject to the
list.
We are in the process of releasing alpha and this discussion is not
delaying alpha, so I believe it comes just in time for 2.2 given the
annoyance of the bug and the fact that it incurs a file format change.

Considering that this situation has been stable for the last 12 years, we could 
also consider that the urgency of changing things just before a release is low, 
especially since  the agreement on what we should do is weak.

Personally, I would prefer to keep it as it is but, as Pavel said, have a 
setting for git-friendly workflow. This requires a bit of design, though.


Yes, it seems to me that there is no consensus here, and that anything 
sensible we could do would involve more changes than we want to make at 
this stage.


Richard

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

[Guillaume Munch]

Le 07/11/2015 22:17, Richard Heck a écrit :

On 11/07/2015 04:46 PM, Jean-Marc Lasgouttes wrote:


Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch  a
écrit :


Yes, I fully understand this point and I agree that a decision has to
be taken somehow quickly, this is why I brought the subject to the
list.
We are in the process of releasing alpha and this discussion is not
delaying alpha, so I believe it comes just in time for 2.2 given the
annoyance of the bug and the fact that it incurs a file format change.

Considering that this situation has been stable for the last 12 years,
we could also consider that the urgency of changing things just before
a release is low, especially since  the agreement on what we should do
is weak.

Personally, I would prefer to keep it as it is but, as Pavel said,
have a setting for git-friendly workflow. This requires a bit of
design, though.


Yes, it seems to me that there is no consensus here, and that anything
sensible we could do would involve more changes than we want to make at
this stage.



Ok. It seems that many people would be happy to see a proper solution, 
but they would also have the time afterwards to evaluate the impact, 
which I understand. In these conditions a quick workaround seems in 
order for 2.2.

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

[Guillaume Munch]

Le 06/11/2015 21:42, Georg Baum a écrit :



I think there is general consensus about \justification and
\output_changes, so if this is OK with Scott you could move these to
preferences, but for \track_changes I do not see a consensus, so this
setting should not be changed so short before a release IMHO.



I think that there are still valid points to be discussed, before we
resort to democracy.



I think everything is on the table now and we can cut down the
discussion to this: can we reach a consensus around adding some form of
document setting that says "Always open this document with change
tracking enabled"?

My impression is that it satisfies both use cases of letting us treat
change tracking as a per-user-per-document setting, and providing us
with a way of distributing copies of change-tracking enabled documents.
It would do so better than what we have now in both cases IMO.

This does not seem inconsistent with what Libreoffice is doing, which
however is not entirely comparable: Libreoffice does indeed store change
tracking, but on the one hand they have the philosophy of storing user
settings in the file unlike LyX, and on the other hand they include two
provisions: 1) for playing nicely with git and 2) for not loading user
settings* if that's not wanted.

(*disclaimer: for the latter I did not check that change tracking
belongs to these non-loaded settings)




Democracy is not the point IMHO: The point is not to further delay the
release. Implementing a small and safe file format change where everybody
agrees that it is useful does not produce a significant delay. Discussing a
controversal change where no easy solution is in sight has the potential of
delaying the release (at least if the possibility of implementing the change
before the release is seriously considered). Therefore I think that it is
not the right time right now to have this discussion.


Yes, I fully understand this point and I agree that a decision has to
be taken somehow quickly, this is why I brought the subject to the list.
We are in the process of releasing alpha and this discussion is not
delaying alpha, so I believe it comes just in time for 2.2 given the
annoyance of the bug and the fact that it incurs a file format change.

The other factor is the schedule for the format freeze which I do not
request to be delayed. If the case above does not convince, or if there
is not enough time before the format freeze, then I am not spending time 
on an half-baked feature and I will just make the most trivial change 
there is to be made to avoid this particular merge conflict.




Guillaume

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

[Vincent van Ravesteijn]

> Democracy is not the point IMHO: The point is not to further delay the
> release. Implementing a small and safe file format change where everybody
> agrees that it is useful does not produce a significant delay. Discussing
a
> controversal change where no easy solution is in sight has the potential
of
> delaying the release (at least if the possibility of implementing the
change
> before the release is seriously considered). Therefore I think that it is
> not the right time right now to have this discussion.
>

Is it really a file format change? If we do not change the physical
appearance of the file format, and if we do not change the document output
of a certain file, is it then still forbidden to change in a minor release?

I mean, it's just a GUI change basically.

Vincent

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

[Jean-Marc Lasgouttes]

Le 06/11/2015 05:37, Pavel Sanda a écrit :

Guillaume Munch wrote:

express any intention. Your description gives the impression that if
your collaborator starts writing and they do not see that the changes
are not being tracked, then they will not know or care about enabling
change tracking, as if they had no clue, and this little button has to
be enabled for them without them to know about it... This seems a bit
far fetched to me.


It is actually were rare that I co-work with geeks and I am very
lucky if I have someone willing to open file in lyx, not to talk
about recognizing what various buttons on toolbar might mean.


First a disclaimer: I do not use change tracking with LyX (otherwise I 
would have implemented hidden deletions long ago :). I do however, use 
it when I am force to collaborate through .doc file (for research 
contracts mostly). And I can tell you the truth:


  People don't know what they are doing.

In this sense, I support keeping a permanent setting for change 
tracking, as a state of a document. I think that the workflow "some of 
the coauthors use CT for fun" is not what should dictate the design of 
the feature.




principle of least surprise: it is not clear for a new user that this is
a purpose of the button. So if what is currently implemented is really
what you have in mind, then it is a very poorly designed feature.


I am not toolbar person and always used menu for toggling, it might
be that toolbar buttons are completely screewed without me noticing :)

Before you started this thread it felt natural that CT on/off state
should be document setting and not otherwise.
How other office packages deal with this?

Pavel

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

[Jean-Marc Lasgouttes]

Le 06/11/2015 10:06, Stephan Witt a écrit :

In this sense there is no need to reduce the likely-hood of merge conflicts
with the state of change tracking. It's not a setting to toggle often, IMHO.


Well, since some people do change it often (if only to piss off their 
co-author :), we could try to see how to mitigate the problem IMO.


JMarc

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

[Vincent van Ravesteijn]

On Fri, Nov 6, 2015 at 10:08 AM, Jean-Marc Lasgouttes
 wrote:
> Le 06/11/2015 10:06, Stephan Witt a écrit :
>>
>> In this sense there is no need to reduce the likely-hood of merge
>> conflicts
>> with the state of change tracking. It's not a setting to toggle often,
>> IMHO.
>
>
> Well, since some people do change it often (if only to piss off their
> co-author :), we could try to see how to mitigate the problem IMO.
>
> JMarc
>

Using change tracking continuously will make a huge mess of your
document. Imagine moving a float one paragraph down, none of your
co-authors cares probably (as the float is floating anyway), but the
on the screen it clutters everything. I always have to take care to
accept the stuff not really relevant for my co-authors to review, such
that they focus on the parts that changed meaning or not. I often
disable change tracking when fixing small things, when incorporating
previous feedback from co-authors, when doing LyX/LaTeX special stuff,
when writing a large new paragraph (it hurts the eyes looking at that
as change) and afterwards I will either cut and paste it to show that
it is added or my coauthors will know that that part is new.

Then, the LyX documentation is supposed to be _the_ workflow in which
the current setting of track changes is optimal. Looking in Math.lyx,
and UserGuide.lyx in master and in 2.1.x, they all have
"\track_changes false". So, it is not working like it is now.

I'm not against having a document setting whether the document is
using track changes or not, I'm just against storing whether I
accidentally had it enabled or not when I saved the document.

Vincent

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

[Stephan Witt]

Am 06.11.2015 um 09:52 schrieb Jean-Marc Lasgouttes :

> Le 06/11/2015 05:37, Pavel Sanda a écrit :
>> Guillaume Munch wrote:
>>> express any intention. Your description gives the impression that if
>>> your collaborator starts writing and they do not see that the changes
>>> are not being tracked, then they will not know or care about enabling
>>> change tracking, as if they had no clue, and this little button has to
>>> be enabled for them without them to know about it... This seems a bit
>>> far fetched to me.
>> 
>> It is actually were rare that I co-work with geeks and I am very
>> lucky if I have someone willing to open file in lyx, not to talk
>> about recognizing what various buttons on toolbar might mean.
> 
> First a disclaimer: I do not use change tracking with LyX (otherwise I would 
> have implemented hidden deletions long ago :). I do however, use it when I am 
> force to collaborate through .doc file (for research contracts mostly). And I 
> can tell you the truth:
> 
>  People don't know what they are doing.
> 
> In this sense, I support keeping a permanent setting for change tracking, as 
> a state of a document. I think that the workflow "some of the coauthors use 
> CT for fun" is not what should dictate the design of the feature.

I'm using change tracking with LyX-documentation only and think this is an
good example for a workflow where the state should be part of the document.
All the co-authors use change tracking and one person is doing the review
and accepts the changes and controls the state of the change tracking.

I agree with Pavel that there is no need for security whistles and bells
to make change tracking mandatory for some document.

In this sense there is no need to reduce the likely-hood of merge conflicts
with the state of change tracking. It's not a setting to toggle often, IMHO.

Stephan

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

[Jean-Marc Lasgouttes]

Le 06/11/2015 02:31, Guillaume Munch a écrit :

Besides the lack of intention conveyed, I already mentioned the
principle of least surprise: it is not clear for a new user that this is
a purpose of the button. So if what is currently implemented is really
what you have in mind, then it is a very poorly designed feature.


In terms of least surprise, I would add that both msword 2007 and 
libreoffice 5 store the setting in the document and consider the 
document as modified when it is changed (although strangely enough word 
does not allow to undo the change via Ctrl+Z).


I check by sending to another computer that the setting is really 
attached to the document and not the user.


JMarc

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

[Guillaume Munch]

Le 06/11/2015 07:01, Vincent van Ravesteijn a écrit :


Op 6 nov. 2015 05:44 schreef "Pavel Sanda" >:
 >
 > Guillaume Munch wrote:
 > > That "CT lock" feature, instead of imposing such a strict constraint
 > > (that could always be circumvented one way or the other...), could
maybe
 > > display instead a message like "Pavel Sanda has requested that changes
 > > be tracked. Are you sure that you want to disable change tracking?".
 > >
 > > But I would like to read more suggestions from you and Günter given
that
 > > you know better than us what you need.
 >
 > No need for locking. I just want to setup defaults which holds for people
 > receiving the document without me explaining how they should edit it.
 > If they know what they are doing (or how to do it:) they are free to
disable it.
 >
 > Pavel

What actually makes sense is to have a document setting like
"under_version_control". When the user opens such a document (for the
first time?) we turn on change tracking.

Important is to not save the current state of change tracking.




I do like this idea. If I understand correctly:

Have a new checkbox in document settings labelled "Open with change
tracking enabled". Then the current state of change tracking is made
independent from this checkbox; only, if the box is checked then it will
do as advertised by the label. Otherwise, the per-user, per-session
setting is restored.

This seems to fit better than the current situation what I understand of
Pavel and other people's use case for change tracking. Indeed, even in
this case, one could want to disable it on purpose momentarily, and this
new setting would mean that one does not need to worry about turning
change tracking back on before saving.

Pavel, is this what you had in mind with "permanent vs. until the end of
the session" ?

Actually we could also treat \output_changes in this way, which makes
even more sense for it given that it affects the output.

Is that convincing?


Guillaume

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

[Guillaume Munch]

Le 06/11/2015 04:37, Pavel Sanda a écrit :

Guillaume Munch wrote:

express any intention. Your description gives the impression that if
your collaborator starts writing and they do not see that the changes
are not being tracked, then they will not know or care about enabling
change tracking, as if they had no clue, and this little button has to
be enabled for them without them to know about it... This seems a bit
far fetched to me.


It is actually were rare that I co-work with geeks and I am very
lucky if I have someone willing to open file in lyx, not to talk
about recognizing what various buttons on toolbar might mean.
If I set all things (e.g. set CT on) and ask just for simple editing
operations I have some chance to go with lyx...
I am not far fetching things but I understand that my experience is
actually hard to transmit if your usuall colleagues are computer
scientist in their 30s or similar.


Note: I am not minimizing your use case. I am only pointing out that
your description was not the best to illustrate your needs and the
reasons behind them. Please understand that it's not necessarily easier
on my side to handle needless merge or rebase conflicts, and my
co-authors are not all used to lyx and git. That conflict in particular
was pointed out to me by my co-author as being a bug in LyX after I
explained what had happened.


Guillaume

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

[Guillaume Munch]

Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit :

Le 06/11/2015 02:31, Guillaume Munch a écrit :

Besides the lack of intention conveyed, I already mentioned the
principle of least surprise: it is not clear for a new user that this is
a purpose of the button. So if what is currently implemented is really
what you have in mind, then it is a very poorly designed feature.


In terms of least surprise, I would add that both msword 2007 and
libreoffice 5 store the setting in the document and consider the
document as modified when it is changed (although strangely enough word
does not allow to undo the change via Ctrl+Z).

I check by sending to another computer that the setting is really
attached to the document and not the user.



Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to 
see if CT was recorded. According to my test, CT is not saved with the 
document. Although ironically the save button gets enabled after 
toggling CT!


Below is the diff. Does that contradict your experiment or have you just 
tried it with Word?


In any case I think the new proposal of a checkbox "Open with change 
tracking enabled" would improve the situation for both use cases.



4c4
< 
2015-11-06T17:33:37.0962274562015-11-06T17:34:51.144047803PT1M13S3LibreOffice/4.4.6.3$Linux_X86_64 
LibreOffice_project/40m0$Build-3meta:image-count="0" meta:object-count="0" meta:page-count="1" 
meta:paragraph-count="1" meta:word-count="1" meta:character-count="4" 
meta:non-whitespace-character-count="4"/>

---
> 
2015-11-06T17:33:37.0962274562015-11-06T17:34:30.707867127PT53S2LibreOffice/4.4.6.3$Linux_X86_64 
LibreOffice_project/40m0$Build-3meta:image-count="0" meta:object-count="0" meta:page-count="1" 
meta:paragraph-count="1" meta:word-count="1" meta:character-count="4" 
meta:non-whitespace-character-count="4"/>

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

[Georg Baum]

Guillaume Munch wrote:

> Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit :
>> Le 06/11/2015 02:31, Guillaume Munch a écrit :
>>
>> In terms of least surprise, I would add that both msword 2007 and
>> libreoffice 5 store the setting in the document and consider the
>> document as modified when it is changed (although strangely enough word
>> does not allow to undo the change via Ctrl+Z).
>>
>> I check by sending to another computer that the setting is really
>> attached to the document and not the user.
>>
> 
> Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to
> see if CT was recorded. According to my test, CT is not saved with the
> document. Although ironically the save button gets enabled after
> toggling CT!
> 
> Below is the diff. Does that contradict your experiment or have you just
> tried it with Word?

libreoffice 4.3.3.2 stores the setting with the document as well:



vs.



in content.xml. I would be surprised if both versions 4.3 and 5 store the 
setting and 4.4 does not store it.


Georg

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

[Georg Baum]

Guillaume Munch wrote:

> Le 05/11/2015 20:25, Georg Baum a écrit :
>> Guillaume Munch wrote:
>>
>>> In addition, what appears even more special to me is the number of times
>>> when it produces the effects that you mention: the only times when a
>>> per-user, per-document preference would not produce the same effect is
>>> the very first time that the user edits the document.
>>
>> I do not understand this sentence.
> 
> With a per-document setting: we are sure that it is always on after
> opening (assuming nobody turns it off)
> 
> With a per-user, per-document setting: we are sure that it is always on
> after opening, except maybe the first time, but then the user has just
> been told to enable change tracking anyway.

Thanks, now I understand. This would not be a problem IMO, if we decide that 
a per-user, per-document setting is the best choice then this follows 
naturally.

>>> I am willing to
>>> bet that that this happened fewer times overall in the past few months
>>> for LyX's documentations than the number of times where I had to
>>> synchronise with my co-author in the same time frame for a single
>>> article. And in any case, having change tracking set automatically on
>>> opening is not enough, because you still have to tell new contributors
>>> that it is important to track changes. Or did I miss something from your
>>> argument?
>>
>> Well, you need to tell them not to mess with certain settings anyway
>> (page format, font size, or all document wide settings, whatever is
>> applicable in the specific context). If they do not change document
>> settings, then everything is OK.
> 
> I am not sure if we agree or if I missed your point.

Then I fear I do not understand what you wanted to say.

>> I think there is general consensus about \justification and
>> \output_changes, so if this is OK with Scott you could move these to
>> preferences, but for \track_changes I do not see a consensus, so this
>> setting should not be changed so short before a release IMHO.
> 
> 
> I think that there are still valid points to be discussed, before we
> resort to democracy.

Democracy is not the point IMHO: The point is not to further delay the 
release. Implementing a small and safe file format change where everybody 
agrees that it is useful does not produce a significant delay. Discussing a 
controversal change where no easy solution is in sight has the potential of 
delaying the release (at least if the possibility of implementing the change 
before the release is seriously considered). Therefore I think that it is 
not the right time right now to have this discussion.

> Also, it would help to have an idea of the schedule for format freeze.

Yes.


Georg

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

[Georg Baum]

Vincent van Ravesteijn wrote:

> What actually makes sense is to have a document setting like
> "under_version_control". When the user opens such a document (for the
> first time?) we turn on change tracking.

What has version control to do with change tracking?


Georg

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

[Guillaume Munch]

Le 06/11/2015 21:28, Georg Baum a écrit :

Guillaume Munch wrote:


Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit :

Le 06/11/2015 02:31, Guillaume Munch a écrit :

In terms of least surprise, I would add that both msword 2007 and
libreoffice 5 store the setting in the document and consider the
document as modified when it is changed (although strangely enough word
does not allow to undo the change via Ctrl+Z).

I check by sending to another computer that the setting is really
attached to the document and not the user.



Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to
see if CT was recorded. According to my test, CT is not saved with the
document. Although ironically the save button gets enabled after
toggling CT!

Below is the diff. Does that contradict your experiment or have you just
tried it with Word?


libreoffice 4.3.3.2 stores the setting with the document as well:



vs.



in content.xml. I would be surprised if both versions 4.3 and 5 store the
setting and 4.4 does not store it.





Cannot reproduce. Enabled change tracking, made a change, saved, and got
. Disabled change
tracking, saved, and got  again. Strangely, even enabling from the
document properties dialog does not change the situation, even though
then I expected it to be saved within the document. Maybe there is an
option to save within the file or not.

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

[Guillaume Munch]

Le 06/11/2015 21:46, Guillaume Munch a écrit :

Le 06/11/2015 21:28, Georg Baum a écrit :

Guillaume Munch wrote:


Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit :

Le 06/11/2015 02:31, Guillaume Munch a écrit :

In terms of least surprise, I would add that both msword 2007 and
libreoffice 5 store the setting in the document and consider the
document as modified when it is changed (although strangely enough word
does not allow to undo the change via Ctrl+Z).

I check by sending to another computer that the setting is really
attached to the document and not the user.



Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to
see if CT was recorded. According to my test, CT is not saved with the
document. Although ironically the save button gets enabled after
toggling CT!

Below is the diff. Does that contradict your experiment or have you just
tried it with Word?


libreoffice 4.3.3.2 stores the setting with the document as well:



vs.



in content.xml. I would be surprised if both versions 4.3 and 5 store the
setting and 4.4 does not store it.





Cannot reproduce. Enabled change tracking, made a change, saved, and got
. Disabled change
tracking, saved, and got  again. Strangely, even enabling from the
document properties dialog does not change the situation, even though
then I expected it to be saved within the document. Maybe there is an
option to save within the file or not.




Mystery solved: I saved into .fodt (Flat odt) instead of .odt assuming 
that it was just the uncompressed original file. Apparently it also 
differs in ways that make it more suitable for versioning systems, like 
not saving such user preferences into files. So, at least Libreoffice 
has provisions to make it easier wrt git (for instance there are line 
breaks everywhere in .fodt files). Note that another provision that 
Libreoffice has is the option of not loading user preferences from files.

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

[Georg Baum]

Vincent van Ravesteijn wrote:

> I think that a regular use-case is that one author writes, and the other
> one provides feedback using track changes.

Yes, I did not think of that (because I prefer giving feedback on paper, and 
if I receive feedback then mostly from people who do not use LyX...)

> Toggling track_changes does not even mark the document as changed, so
> you cannot save it. So, when I'm ready writing and I want my
> collaborator to use track changes, I'll have turn on track changes, make
> a change, undo the change, and save.

This is of course a bug. Toggling any setting that is stored in the document 
must make it saveable.


Georg

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

[Georg Baum]

Guillaume Munch wrote:

> Le 04/11/2015 20:06, Georg Baum a écrit :
> 
> My experience with multi-author collaboration and change tracking
> differs. The various portions of the document tend to "belong" to one
> author and an author uses change tracking depending on whether that part
> belongs to them. Also, for trivial edits (typos...) they would disable
> change tracking. This is from my actual experience. So we tend to switch
> change tracking many times. The interface tends to concur with this
> usage: it is located on a toolbar and is assigned a keyboard shortcut.
> 
> On the contrary, the use case that you mention where everybody has to
> track changes at the same time seems to be due to external constraints:
> change tracking is not used to facilitate multi-author collaboration,
> but to facilitate translations. This use of change-tracking appears very
> special to me.
> 
> In addition, what appears even more special to me is the number of times
> when it produces the effects that you mention: the only times when a
> per-user, per-document preference would not produce the same effect is
> the very first time that the user edits the document.

I do not understand this sentence.

> I am willing to
> bet that that this happened fewer times overall in the past few months
> for LyX's documentations than the number of times where I had to
> synchronise with my co-author in the same time frame for a single
> article. And in any case, having change tracking set automatically on
> opening is not enough, because you still have to tell new contributors
> that it is important to track changes. Or did I miss something from your
> argument?

Well, you need to tell them not to mess with certain settings anyway (page 
format, font size, or all document wide settings, whatever is applicable in 
the specific context). If they do not change document settings, then 
everything is OK.

> Another argument is the principle of least surprise: I think that users
> would tend to assume that it is a per-user, per-document preference,
> similar to the last cursor position mentioned by Vincent. Currently, it
> is more confusing, in the context where change tracking is enabled
> intermittently, that my co-author gets my own latest state instead of
> their.

I understand your use case now (which I was not so aware of previously), but 
as you can see from the other responses, not all people work like that, so 
we are back to the beginning: There is no easy solution, it depends on the 
use case whether you want to store that in a document or in preferences.

> I agree with Vincent: \justification is per user, and the other two are
> per user, per document.

I think there is general consensus about \justification and \output_changes, 
so if this is OK with Scott you could move these to preferences, but for 
\track_changes I do not see a consensus, so this setting should not be 
changed so short before a release IMHO.


Georg

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

[Pavel Sanda]

Guillaume Munch wrote:
> express any intention. Your description gives the impression that if
> your collaborator starts writing and they do not see that the changes
> are not being tracked, then they will not know or care about enabling
> change tracking, as if they had no clue, and this little button has to
> be enabled for them without them to know about it... This seems a bit
> far fetched to me.

It is actually were rare that I co-work with geeks and I am very
lucky if I have someone willing to open file in lyx, not to talk 
about recognizing what various buttons on toolbar might mean.
If I set all things (e.g. set CT on) and ask just for simple editing
operations I have some chance to go with lyx...
I am not far fetching things but I understand that my experience is 
actually hard to transmit if your usuall colleagues are computer
scientist in their 30s or similar.

> principle of least surprise: it is not clear for a new user that this is
> a purpose of the button. So if what is currently implemented is really
> what you have in mind, then it is a very poorly designed feature.

I am not toolbar person and always used menu for toggling, it might
be that toolbar buttons are completely screewed without me noticing :)

Before you started this thread it felt natural that CT on/off state
should be document setting and not otherwise.
How other office packages deal with this?

Pavel

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

[Pavel Sanda]

Guillaume Munch wrote:
> So we tend to switch change tracking many times.

Would be distinguishing between CT-on 'permanent' vs 'this session only'
(automatically discarded when file is closed) of any help?

Pavel

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

[Pavel Sanda]

Guillaume Munch wrote:
> That "CT lock" feature, instead of imposing such a strict constraint
> (that could always be circumvented one way or the other...), could maybe
> display instead a message like "Pavel Sanda has requested that changes
> be tracked. Are you sure that you want to disable change tracking?".
>
> But I would like to read more suggestions from you and Günter given that
> you know better than us what you need.

No need for locking. I just want to setup defaults which holds for people
receiving the document without me explaining how they should edit it.
If they know what they are doing (or how to do it:) they are free to disable it.

Pavel

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

[Scott Kostyshak]

On Fri, Nov 06, 2015 at 01:41:22AM +, Guillaume Munch wrote:

> >I think there is general consensus about \justification and \output_changes,
> >so if this is OK with Scott you could move these to preferences, but for
> >\track_changes I do not see a consensus, so this setting should not be
> >changed so short before a release IMHO.
> 
> 
> I think that there are still valid points to be discussed, before we resort
> to democracy.

OK ping me again if there is consensus.

> Also, it would help to have an idea of the schedule for format freeze.

OK I will work on a schedule next week, after alpha is released and
after we find out whether Qt 5.6 beta is delayed again.

Scott

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

[Guillaume Munch]

Le 05/11/2015 07:31, Vincent van Ravesteijn a écrit :

On Thu, Nov 5, 2015 at 7:12 AM, Pavel Sanda  wrote:

Vincent van Ravesteijn wrote:

I consider it also document, not user, setting. It would cause confusions
if this setting is not transfered to my collaborators within the document.


I disagree. There is no confusion possible.


It is. When the document circles I want the CT be part of document
setting not dependent whether this or another collaborator forgot
to switch CT.





Pavel, I agree with Vincent that we need to think more about your use
case. Given what you seem to use it for (though maybe you and Günter
could expand a bit more on your expectations for more clarity), the
current situation does not seem ideal given that the interface does not
express any intention. Your description gives the impression that if
your collaborator starts writing and they do not see that the changes
are not being tracked, then they will not know or care about enabling
change tracking, as if they had no clue, and this little button has to
be enabled for them without them to know about it... This seems a bit
far fetched to me.

Besides the lack of intention conveyed, I already mentioned the
principle of least surprise: it is not clear for a new user that this is
a purpose of the button. So if what is currently implemented is really
what you have in mind, then it is a very poorly designed feature.

To expand on Vincent's suggestion:


Maybe that could be a new feature: "Editing this document is only
allowed with track changes on. Track changes can only be turned off by
the one that "locked" the file".



That "CT lock" feature, instead of imposing such a strict constraint
(that could always be circumvented one way or the other...), could maybe
display instead a message like "Pavel Sanda has requested that changes
be tracked. Are you sure that you want to disable change tracking?".

But I would like to read more suggestions from you and Günter given that
you know better than us what you need.



Guillaume

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

[Guillaume Munch]

Le 05/11/2015 20:25, Georg Baum a écrit :

Guillaume Munch wrote:


Le 04/11/2015 20:06, Georg Baum a écrit :

My experience with multi-author collaboration and change tracking
differs. The various portions of the document tend to "belong" to one
author and an author uses change tracking depending on whether that part
belongs to them. Also, for trivial edits (typos...) they would disable
change tracking. This is from my actual experience. So we tend to switch
change tracking many times. The interface tends to concur with this
usage: it is located on a toolbar and is assigned a keyboard shortcut.

On the contrary, the use case that you mention where everybody has to
track changes at the same time seems to be due to external constraints:
change tracking is not used to facilitate multi-author collaboration,
but to facilitate translations. This use of change-tracking appears very
special to me.

In addition, what appears even more special to me is the number of times
when it produces the effects that you mention: the only times when a
per-user, per-document preference would not produce the same effect is
the very first time that the user edits the document.


I do not understand this sentence.


With a per-document setting: we are sure that it is always on after
opening (assuming nobody turns it off)

With a per-user, per-document setting: we are sure that it is always on
after opening, except maybe the first time, but then the user has just
been told to enable change tracking anyway.




I am willing to
bet that that this happened fewer times overall in the past few months
for LyX's documentations than the number of times where I had to
synchronise with my co-author in the same time frame for a single
article. And in any case, having change tracking set automatically on
opening is not enough, because you still have to tell new contributors
that it is important to track changes. Or did I miss something from your
argument?


Well, you need to tell them not to mess with certain settings anyway (page
format, font size, or all document wide settings, whatever is applicable in
the specific context). If they do not change document settings, then
everything is OK.


I am not sure if we agree or if I missed your point.




Another argument is the principle of least surprise: I think that users
would tend to assume that it is a per-user, per-document preference,
similar to the last cursor position mentioned by Vincent. Currently, it
is more confusing, in the context where change tracking is enabled
intermittently, that my co-author gets my own latest state instead of
their.


I understand your use case now (which I was not so aware of previously), but
as you can see from the other responses, not all people work like that, so
we are back to the beginning: There is no easy solution, it depends on the
use case whether you want to store that in a document or in preferences.


See my other message from today about this point. (Essentially, I am not 
sure that the current situation satisfies any of the use case.)





I agree with Vincent: \justification is per user, and the other two are
per user, per document.


I think there is general consensus about \justification and \output_changes,
so if this is OK with Scott you could move these to preferences, but for
\track_changes I do not see a consensus, so this setting should not be
changed so short before a release IMHO.



I think that there are still valid points to be discussed, before we 
resort to democracy.


Also, it would help to have an idea of the schedule for format freeze.


Guillaume

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

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> What actually makes sense is to have a document setting like
> "under_version_control". When the user opens such a document (for the first
> time?) we turn on change tracking.

Not sure I am following what you propose.
under_version_control is related to our VCS machinery or independent?

> Important is to not save the current state of change tracking.

Is this different from the "permanent" vs "current session only" solution
I proposed in the other mail?

Pavel

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

[Vincent van Ravesteijn]

Op 6 nov. 2015 05:44 schreef "Pavel Sanda" :
>
> Guillaume Munch wrote:
> > That "CT lock" feature, instead of imposing such a strict constraint
> > (that could always be circumvented one way or the other...), could maybe
> > display instead a message like "Pavel Sanda has requested that changes
> > be tracked. Are you sure that you want to disable change tracking?".
> >
> > But I would like to read more suggestions from you and Günter given that
> > you know better than us what you need.
>
> No need for locking. I just want to setup defaults which holds for people
> receiving the document without me explaining how they should edit it.
> If they know what they are doing (or how to do it:) they are free to
disable it.
>
> Pavel

What actually makes sense is to have a document setting like
"under_version_control". When the user opens such a document (for the first
time?) we turn on change tracking.

Important is to not save the current state of change tracking.

Vincent

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

[Vincent van Ravesteijn]

Op 4-11-2015 om 21:06 schreef Georg Baum:

Guillaume Munch wrote:


Le 03/11/2015 21:16, Georg Baum a écrit :

I don't think there is an easy solution, because it depends on the use
case. For example, in our documentation workflows \tracking_changes needs
to be the same for all users, so this should not go into the preferences.
For the other two I am not sure.


For context:

\track_changes : whether the track changes button is enabled (does not
affect the existing contents)

But it affects what happens if a change is made to the document. One author
using change tracking and the next one making changes without change
tracking is a very special case IMO. The usual case is that either all
authors or nobody uses change tracking for a particular document. For
example, in our own docs, we require everybody to use change tracking so
that the translations can be updated. Therefore it should be switched on all
the time.
I think that a regular use-case is that one author writes, and the other 
one provides feedback using track changes.


Toggling track_changes does not even mark the document as changed, so 
you cannot save it. So, when I'm ready writing and I want my 
collaborator to use track changes, I'll have turn on track changes, make 
a change, undo the change, and save.


Vincent

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

[Guillaume Munch]

Le 04/11/2015 20:06, Georg Baum a écrit :

Guillaume Munch wrote:


Le 03/11/2015 21:16, Georg Baum a écrit :


I don't think there is an easy solution, because it depends on the use
case. For example, in our documentation workflows \tracking_changes needs
to be the same for all users, so this should not go into the preferences.
For the other two I am not sure.



For context:

\track_changes : whether the track changes button is enabled (does not
affect the existing contents)


But it affects what happens if a change is made to the document. One author
using change tracking and the next one making changes without change
tracking is a very special case IMO. The usual case is that either all
authors or nobody uses change tracking for a particular document. For
example, in our own docs, we require everybody to use change tracking so
that the translations can be updated. Therefore it should be switched on all
the time.




My experience with multi-author collaboration and change tracking
differs. The various portions of the document tend to "belong" to one
author and an author uses change tracking depending on whether that part
belongs to them. Also, for trivial edits (typos...) they would disable
change tracking. This is from my actual experience. So we tend to switch
change tracking many times. The interface tends to concur with this
usage: it is located on a toolbar and is assigned a keyboard shortcut.

On the contrary, the use case that you mention where everybody has to
track changes at the same time seems to be due to external constraints:
change tracking is not used to facilitate multi-author collaboration,
but to facilitate translations. This use of change-tracking appears very
special to me.

In addition, what appears even more special to me is the number of times
when it produces the effects that you mention: the only times when a
per-user, per-document preference would not produce the same effect is
the very first time that the user edits the document. I am willing to
bet that that this happened fewer times overall in the past few months
for LyX's documentations than the number of times where I had to
synchronise with my co-author in the same time frame for a single
article. And in any case, having change tracking set automatically on
opening is not enough, because you still have to tell new contributors
that it is important to track changes. Or did I miss something from your
argument?

Another argument is the principle of least surprise: I think that users
would tend to assume that it is a per-user, per-document preference,
similar to the last cursor position mentioned by Vincent. Currently, it
is more confusing, in the context where change tracking is enabled
intermittently, that my co-author gets my own latest state instead of their.

I agree with Vincent: \justification is per user, and the other two are
per user, per document.


Guillaume

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

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> > I consider it also document, not user, setting. It would cause confusions
> > if this setting is not transfered to my collaborators within the document.
> 
> I disagree. There is no confusion possible.

It is. When the document circles I want the CT be part of document
setting not dependent whether this or another collaborator forgot
to switch CT.

Pavel

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

[Guenter Milde]

On 2015-11-05, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
>> > I consider it also document, not user, setting. It would cause confusions
>> > if this setting is not transfered to my collaborators within the document.

>> I disagree. There is no confusion possible.

> It is. When the document circles I want the CT be part of document
> setting not dependent whether this or another collaborator forgot
> to switch CT.

+1

Günter

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

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 7:12 AM, Pavel Sanda  wrote:
> Vincent van Ravesteijn wrote:
>> > I consider it also document, not user, setting. It would cause confusions
>> > if this setting is not transfered to my collaborators within the document.
>>
>> I disagree. There is no confusion possible.
>
> It is. When the document circles I want the CT be part of document
> setting not dependent whether this or another collaborator forgot
> to switch CT.
>

Maybe that could be a new feature: "Editing this document is only
allowed with track changes on. Track changes can only be turned off by
the one that "locked" the file".

Vincent

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

[Georg Baum]

Guillaume Munch wrote:

> Le 03/11/2015 21:16, Georg Baum a écrit :
>>
>> I don't think there is an easy solution, because it depends on the use
>> case. For example, in our documentation workflows \tracking_changes needs
>> to be the same for all users, so this should not go into the preferences.
>> For the other two I am not sure.
>>
> 
> For context:
> 
> \track_changes : whether the track changes button is enabled (does not
> affect the existing contents)

But it affects what happens if a change is made to the document. One author 
using change tracking and the next one making changes without change 
tracking is a very special case IMO. The usual case is that either all 
authors or nobody uses change tracking for a particular document. For 
example, in our own docs, we require everybody to use change tracking so 
that the translations can be updated. Therefore it should be switched on all 
the time.


Georg

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

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 1:50 AM, Guillaume Munch  wrote:
> Le 03/11/2015 21:16, Georg Baum a écrit :
>>
>> Guillaume Munch wrote:
>>
>>> 
>>>
>>> I am bringing this to the list due to the timing, due to the fact that
>>> it is a file format change, and due to the fact that it looks severe in
>>> the above context.
>>>
>>> I suggest moving these settings to the user preferences.
>>>
>>> Can we agree on the issue? On the solution? Is it easy to do?
>>
>>
>> I don't think there is an easy solution, because it depends on the use
>> case.
>> For example, in our documentation workflows \tracking_changes needs to be
>> the same for all users, so this should not go into the preferences. For
>> the
>> other two I am not sure.
>>
>
> For context:
>
> \justification : whether justification is displayed in the LyX window (does
> not affect output)

user preference.

>
> \track_changes : whether the track changes button is enabled (does not
> affect the existing contents)

user-per-document preference.

>
> \output_changes : whether the changes are displayed in the output (I can
> agree that this one could be considered as part of the document.)
>

user-per-document preference.

> Also, is there a way to have settings which are per-user *and* per-file?
>

Yes, we write for instance the cursor position per file into the session file.

Vincent

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

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 7:26 AM, Pavel Sanda  wrote:
> Guillaume Munch wrote:
>> For \track_changes, I do not understand your rationale for making it a
>> setting of the document. It is not locked on, so the user who edits the
>> documentations has to know in any case that he should track changes (if I
>> had not been told to, then I'd have turned it off even if it was on).
>
> I consider it also document, not user, setting. It would cause confusions
> if this setting is not transfered to my collaborators within the document.
>

I disagree. There is no confusion possible.

If it was, then we should also make the cursor position a document
property, so my collaborator would not be confused where to start
writing ...

Vincent

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

[Georg Baum]

Guillaume Munch wrote:

> 
> 
> I am bringing this to the list due to the timing, due to the fact that
> it is a file format change, and due to the fact that it looks severe in
> the above context.
> 
> I suggest moving these settings to the user preferences.
> 
> Can we agree on the issue? On the solution? Is it easy to do?

I don't think there is an easy solution, because it depends on the use case. 
For example, in our documentation workflows \tracking_changes needs to be 
the same for all users, so this should not go into the preferences. For the 
other two I am not sure.


Georg

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

[Guillaume Munch]

Le 03/11/2015 19:49, LyX Ticket Tracker a écrit :

#9841: Preferences specific to the user and not to the file should not be 
recorded
in the file
-+
  Reporter:  gadmm|  Owner:  lasgouttes
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  2.2.0
Component:  general  |Version:  2.1.4
  Severity:  normal   |   Keywords:  fileformat
-+
  Preferences specific to the user and not to the file should not be
  recorded in the file, for instance the following:

  \justification
  \tracking_changes
  \output_changes

  The problem is when collaborating on a file and using a versioning system
  like git. Then, these settings cause needless conflicts. For
  \justification, we can simply agree on a setting, but for
  \tracking_changes and \output_changes, it is normal to turn them on and
  off many times. There is an irony to the fact that change tracking is
  meant to help with collaborative works (in fact an aggravating factor)…

  This is a great annoyance, and obviously a file format change.





I am bringing this to the list due to the timing, due to the fact that 
it is a file format change, and due to the fact that it looks severe in 
the above context.


I suggest moving these settings to the user preferences.

Can we agree on the issue? On the solution? Is it easy to do?



Guillaume

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

[Guillaume Munch]

Le 03/11/2015 21:16, Georg Baum a écrit :

Guillaume Munch wrote:




I am bringing this to the list due to the timing, due to the fact that
it is a file format change, and due to the fact that it looks severe in
the above context.

I suggest moving these settings to the user preferences.

Can we agree on the issue? On the solution? Is it easy to do?


I don't think there is an easy solution, because it depends on the use case.
For example, in our documentation workflows \tracking_changes needs to be
the same for all users, so this should not go into the preferences. For the
other two I am not sure.



For context:

\justification : whether justification is displayed in the LyX window 
(does not affect output)


\track_changes : whether the track changes button is enabled (does not 
affect the existing contents)


\output_changes : whether the changes are displayed in the output (I can 
agree that this one could be considered as part of the document.)



For \justification, it seems obvious that this is a personal preference 
similar to the display font which should go to the preferences dialog.


For \track_changes, I do not understand your rationale for making it a 
setting of the document. It is not locked on, so the user who edits the 
documentations has to know in any case that he should track changes (if 
I had not been told to, then I'd have turned it off even if it was on).


I do not understand what you mean with "has to be the same for all 
users". It happens to be the same for all users in this case, but this 
setting is not sufficient (nor essential) for the workflow. (Also, while 
ensuring that it does what I described, I noticed that the save button 
remained disabled after altering change tracking. If it's really part of 
the document, then pushing the change tracking button should enable the 
save button!)



Also, is there a way to have settings which are per-user *and* per-file?


Lastly, in any case, conflicts do not always happen, because these 
settings are booleans, so there are only two possible configurations for 
each (conflicts happen when there are 3 different configurations). In my 
case the conflict happened because \tracking_changes and \output_changes 
are next to one another so they are treated as one by git (thus with 
four possible configurations). A solution to this particular conflict 
issue would be to not write them next to one another. But this would be 
a hack, as it is still annoying to agree about personal settings with 
co-authors.


For \output_changes, I only use it in a temporary fashion so it's more 
of a personal setting, but in any case it's ok if we keep it because of 
the previous reason: boolean settings cannot create conflicts on their 
own. So when there's just one it's fine, it's when there are many such 
settings that we have problems.



Guillaume

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

[Pavel Sanda]

Guillaume Munch wrote:
> For \track_changes, I do not understand your rationale for making it a 
> setting of the document. It is not locked on, so the user who edits the 
> documentations has to know in any case that he should track changes (if I 
> had not been told to, then I'd have turned it off even if it was on).

I consider it also document, not user, setting. It would cause confusions
if this setting is not transfered to my collaborators within the document.

In case it's helpful it should be trivial to change lyx format so that
output_changes & tracking_changes entries are more distant in git diffs.

Pavel