'make check' failing
test-suite.log shows the following: LyX 2.2.0dev: src/frontends/test-suite.log # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: tests/test_biblio === terminate called after throwing an instance of 'std::regex_error' what(): regex_error Aborted (core dumped) Scott
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
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
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
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
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
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
