Re: dash documentation patch
Dear Scott, dear Enrico, dear lyx developers, On 2017-09-02, Scott Kostyshak wrote: > On Sat, Sep 02, 2017 at 12:34:05AM +0200, Enrico Forestieri wrote: >> On Thu, Aug 31, 2017 at 08:53:41PM +, Guenter Milde wrote: >> See above. Release notes should be used to illustrate current changes, not >> changes occurred in past releases. > From what I understand, if we could go back in time (but could not fix > anything in the code), we would add notes to release notes for the LyX > 2.2.0 release. That is not possible. So the question is do we put them > in the release notes for 2.3.0 or leave them absent from any release > notes? We cannot go back in time, but git branches allow at least a fix: we can amend the RELEASE NOTES in the 2.2.x branch. The question is, who is going to read it? > I wonder if a similar situation has come up before and what we did. > It is true that we have a subsection "Caveats when upgrading from > earlier versions to 2.3.x", and indeed 2.1.x is an "earlier version". > However, the title of the file is "Important Changes in LyX 2.3.0", > which in my opinion dominates any implication of a subtitle. Some consequences of the changes in 2.2.0 came only to our attention during the 2.3 development cycle. IMO, it is a pragmatic solution to add this insight in the 2.3 RELEASE NOTES. > One line of logic is: suppose the release notes for 2.2.0 were accurate. > Do we really think that 2.1.x users would read both the release notes of > 2.2.0 and of 2.3.0 before upgrading? Probably not. So the fact that the > release notes for 2.2.0 are inaccurate might not be so relevant. This is > all just guessing about user-behavior on my part though. And I must > admit that when I personally upgrade software that's important to me, I > would read all of the release notes in-between. > I think the best solution might be the following: > In the RELEASE-NOTES file, we could reference > https://wiki.lyx.org/LyX/ReleaseNotes for release notes relating to > previous versions of LyX. Actually, I need to update that Wiki page. > e.g. we could put "If upgrading from a pre-2.2 LyX version, please see > https://wiki.lyx.org/LyX/ReleaseNotes;, and on that Wiki page we can > list both the original release notes as well as any "post 2.2-release > addendums", where issues such as what Günter details could be listed. > If it is decided that this proposal is too complicated, we could > perhaps include a very concise note in the 2.3 release notes along the > lines of "if upgrading from pre-2.2, please read for > considerations related to dashes". The problem is, however, that users upgrading from 2.2 have read the 2.2.0 RELEASE NOTES already and won't see the need to re-read them, thus missing the information. Nevertheless, they are still affected by the changes when opening pre-2.2 documents (and will forever, as we voted not to revert the decision to merge literal and ligature dashes in the LyX source). A link to the ReleaseNotes wiki page is still a good idea, as we do not ship a "Changelog" file. Günter
Re: dash documentation patch
On Sat, Sep 02, 2017 at 12:34:05AM +0200, Enrico Forestieri wrote: > On Thu, Aug 31, 2017 at 08:53:41PM +, Guenter Milde wrote: > > This also one of the caveats then upgrading from earlier versions (which are > > not limited to upgrading from 2.2). > > See above. Release notes should be used to illustrate current changes, not > changes occurred in past releases. From what I understand, if we could go back in time (but could not fix anything in the code), we would add notes to release notes for the LyX 2.2.0 release. That is not possible. So the question is do we put them in the release notes for 2.3.0 or leave them absent from any release notes? I wonder if a similar situation has come up before and what we did. It is true that we have a subsection "Caveats when upgrading from earlier versions to 2.3.x", and indeed 2.1.x is an "earlier version". However, the title of the file is "Important Changes in LyX 2.3.0", which in my opinion dominates any implication of a subtitle. One line of logic is: suppose the release notes for 2.2.0 were accurate. Do we really think that 2.1.x users would read both the release notes of 2.2.0 and of 2.3.0 before upgrading? Probably not. So the fact that the release notes for 2.2.0 are inaccurate might not be so relevant. This is all just guessing about user-behavior on my part though. And I must admit that when I personally upgrade software that's important to me, I would read all of the release notes in-between. I think the best solution might be the following: In the RELEASE-NOTES file, we could reference https://wiki.lyx.org/LyX/ReleaseNotes for release notes relating to previous versions of LyX. Actually, I need to update that Wiki page. e.g. we could put "If upgrading from a pre-2.2 LyX version, please see https://wiki.lyx.org/LyX/ReleaseNotes;, and on that Wiki page we can list both the original release notes as well as any "post 2.2-release addendums", where issues such as what Günter details could be listed. If it is decided that this proposal is too complicated, we could perhaps include a very concise note in the 2.3 release notes along the lines of "if upgrading from pre-2.2, please read for considerations related to dashes". Scott signature.asc Description: PGP signature
Re: Improving the shell-escape warning when a global converter has -shell-escape
On Thu, Aug 31, 2017 at 07:12:28PM +0200, Tommaso Cucinotta wrote: > On 31/08/2017 02:45, Scott Kostyshak wrote: > > feature, first remove the -shell-escape option from the global > > converter by going to Preferences > file handling > converters, > > removing "-shell-escape" from the corresponding converter, and > > clicking on "Modify" and then "Save". > > > > Any thoughts or alternative improvements? > > offer a button on that warning dialog that does this for the user. Interesting idea. I hadn't thought about that. A button could at most remove the global -shell-escape and enable it for the particular document. But it wouldn't help any other document that needs -shell-escape. Also, I'm worried that a user would click on the "automatic fix" button without thinking, even if their document didn't need -shell-escape. At first thought, I don't like the idea of the button adding the document-specific -shell-escape. Also at first thought, I do think I like the idea of a button that just focuses on removing -shell-escape from the global converter, if we were very clear to the user what was going on (and that they would have to enable it manually for each document that needed it). Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 31, 2017 at 01:07:46PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > I did not make any stats, cherrypicking single commit (likely close to > > > worst-case) gives me uncompressed 45 megs in blobs: > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > cat-file --batch-check |acut -f 3|asum > > > 45175575 > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > to know. > > No, 45MB uncompressed per _single_ commit. P Ah, thanks for the clarification. Scott signature.asc Description: PGP signature
Re: are pocheck.pl warnings useful?
On Thu, Aug 31, 2017 at 09:16:15AM +0200, Jean-Pierre Chrétien wrote: > Le 31/08/2017 à 07:06, Scott Kostyshak a écrit : > > Does pocheck.pl provide useful warnings? > > > > For example, with > > > > ./pocheck.pl de.po > > > > I get: > > > > [cut] > > Bad Qt shortcuts: 7 > > Bad menu shortcuts: 20 > > Bad spaces: 8 > > Bad colons: 7 > > Bad periods: 77 > > Inconsistent translations: 59 > > Total warnings: 178 > > Sure > Bad shortcuts: useful to detect missing shortcuts (may be needed to avoid >conflicts, just a reminder then) > Bad spaces: will not happen anymore but for really untranslated ending spaces > in LabelString fields once #10723 is resolved (but there are other > instances) > Bad colons: useful to detect untranslated colons > Bad periods: numerous because currently the messages are not consistent w.r.t > ending colons (in French also, I added some when I felt it > needed) > Inconsistent translations: reminders mostly, note that pocheck.pl should be > made >case insensitive, as e.g. > > Different translations for 'undefined': > Line 32811: 'undefined' => 'indéfini' > Line 15669: 'UNDEFINED' => 'INDÉFINI' > > does not need to appear as a warning. I will give a try when I have some > time (I used to be fluent in Perl). Thanks. I will try to use pocheck when translators send po files, to see if I can catch any regressions. Scott signature.asc Description: PGP signature
