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
