Re: Standalone Math Editor
Thanks a lot! I'm trying Lyxserver and Lyx functions. They are amazing. I can just send commands to open a document and insert a display math! One problem seems that there is no Lyx function allowing me to get the content of math. I can use select and copy to put it into clipboard, then maybe read the clipboard to get the content. This seems not very elegant and reliable? Another problem is that I don't know how to return to the editor. That seems a much harder problem. Wei-Ting
Re: git.lyx.org - developers! your ssh public key please
Good points, Yihui. I think you are right that on Github small contributers would be more likely to stick around, improve their skills, and possibly become more major contributors. At some point, I think a transition would be wise in order to take advantage of new tools that make things easier. I have no idea if that point is now or in a few years. I think that depends on if someone volunteers to take the lead. Best, Scott On Sun, Feb 19, 2017 at 10:31:37PM -0600, Yihui Xie wrote: > Hi Scott, > > I agree with everything you said.. If it were five years ago, it would > be very likely that I'd volunteer to help with the transition if the > LyX development team want. Unfortunately I have got more open source > projects to work on than I can really afford now. That said, things > can be a lot easier if we don't migrate old issues on Trac but just > lock the system and direct future users to Github. I think moving the > GIT repo to Github is very straightforward. The Wiki is a little > tricky, and I don't know what to do with it. The lyx.org website can > actually be switched to a Markdown-based website, too. For example, > Hugo is an amazing static website generator. You can host the > Markdown-based website on Github and build it to HTML automatically on > push (e.g. you can hook the website repo with Netlify for free). There > are just so many amazing modern free tools to use now, and the > development team can spend much less time on maintaining all backend > tools and servers. All I can promise now is that I can provide > suggestions on tools/platforms to use, but I cannot take the lead to > make the transition. > > Bottom line: if we wish LyX longevity, I believe the right way is not > to work as hard as the LyX team can, but to make it part of the life > of as many users as possible. From my experience of merging probably a > few hundreds pull requests on Github, if a user can contribute a typo > fix easily (without having to email back and forth), it is likely that > he/she can bring more significant fixes in the future, and the project > is likely to be part of his/her life, because he/she feels encouraged > to contribute. > > Regards, > Yihui > -- > https://yihui.name > > > On Sun, Feb 19, 2017 at 3:52 PM, Scott Kostyshak wrote: > > Thanks for the link, Yihui. It is an interesting read. > > > > First I want to say that I really don't know much about Git or our > > current system, so I don't really trust myself on these matters. But > > that said, I'll give my opinion. > > > > I think if everything were already on Github, it would be better. But I > > think the transition to it would not be trivial. If someone were serious > > about taking the lead and taking care of *everything* about the > > transition, then I would personally be in favor of it. > > > > If no one steps up to take the lead, then I would not feel comfortable > > if it were just a few people who all said "yeah I can help a little" > > because I think things would get stuck in the mud and it would be a > > mess. I really think we would need someone to lead. > > > > I don't think Yihui was volunteering to take the lead. If, however, he > > were interested (and he should not be, because it would be a burden) in > > accepting responsibility for everything, I would feel comfortable going > > forward. This is because I know Yihui's work and trust him as a > > developer and a person. > > > > As for the benefits (i.e., why I would be in favor if to my surprise > > someone does want to accept responsibility for the transition), I see > > several benefits: > > > > - Patches would not be left to rot. We could easily see in the "pull > > requests" tab which patches are still pending. > > - There would be no down time. Our server is having problems. Just > > yesterday either trac was not working for me or it would take 1 minute > > to load a ticket. > > - We don't have to worry about upgrading trac (our 0.12.5 version is > > based on the 0.12 major version, which was released in June 2010). > > - An increase in minor contributions. I personally don't think the > > number of serious, long-time contributors will change as the result of > > the transition. But I do think that minor patches and "drive-by > > contributions", and e.g. fixes of typos would increase and I think > > that minor patches are important and can add up. > > - We won't have problems with Trac losing all users (one time I think > > everyone had to re-register). > > - In trac, it is hard to get a response from a reporter of a bug report > > from 5 years ago because they often have changed their email address. > > With Github, if they change the email address, they will still be > > notified. > > - We will get more bug reports and enhancement requests. Although it is > > silly, I'm sure many people do not make bug reports because they do > > not want to register. Many are already registered on Github. > > - Even if our server did not have problem
Re: git.lyx.org - developers! your ssh public key please
Hi Scott, I agree with everything you said.. If it were five years ago, it would be very likely that I'd volunteer to help with the transition if the LyX development team want. Unfortunately I have got more open source projects to work on than I can really afford now. That said, things can be a lot easier if we don't migrate old issues on Trac but just lock the system and direct future users to Github. I think moving the GIT repo to Github is very straightforward. The Wiki is a little tricky, and I don't know what to do with it. The lyx.org website can actually be switched to a Markdown-based website, too. For example, Hugo is an amazing static website generator. You can host the Markdown-based website on Github and build it to HTML automatically on push (e.g. you can hook the website repo with Netlify for free). There are just so many amazing modern free tools to use now, and the development team can spend much less time on maintaining all backend tools and servers. All I can promise now is that I can provide suggestions on tools/platforms to use, but I cannot take the lead to make the transition. Bottom line: if we wish LyX longevity, I believe the right way is not to work as hard as the LyX team can, but to make it part of the life of as many users as possible. From my experience of merging probably a few hundreds pull requests on Github, if a user can contribute a typo fix easily (without having to email back and forth), it is likely that he/she can bring more significant fixes in the future, and the project is likely to be part of his/her life, because he/she feels encouraged to contribute. Regards, Yihui -- https://yihui.name On Sun, Feb 19, 2017 at 3:52 PM, Scott Kostyshak wrote: > Thanks for the link, Yihui. It is an interesting read. > > First I want to say that I really don't know much about Git or our > current system, so I don't really trust myself on these matters. But > that said, I'll give my opinion. > > I think if everything were already on Github, it would be better. But I > think the transition to it would not be trivial. If someone were serious > about taking the lead and taking care of *everything* about the > transition, then I would personally be in favor of it. > > If no one steps up to take the lead, then I would not feel comfortable > if it were just a few people who all said "yeah I can help a little" > because I think things would get stuck in the mud and it would be a > mess. I really think we would need someone to lead. > > I don't think Yihui was volunteering to take the lead. If, however, he > were interested (and he should not be, because it would be a burden) in > accepting responsibility for everything, I would feel comfortable going > forward. This is because I know Yihui's work and trust him as a > developer and a person. > > As for the benefits (i.e., why I would be in favor if to my surprise > someone does want to accept responsibility for the transition), I see > several benefits: > > - Patches would not be left to rot. We could easily see in the "pull > requests" tab which patches are still pending. > - There would be no down time. Our server is having problems. Just > yesterday either trac was not working for me or it would take 1 minute > to load a ticket. > - We don't have to worry about upgrading trac (our 0.12.5 version is > based on the 0.12 major version, which was released in June 2010). > - An increase in minor contributions. I personally don't think the > number of serious, long-time contributors will change as the result of > the transition. But I do think that minor patches and "drive-by > contributions", and e.g. fixes of typos would increase and I think > that minor patches are important and can add up. > - We won't have problems with Trac losing all users (one time I think > everyone had to re-register). > - In trac, it is hard to get a response from a reporter of a bug report > from 5 years ago because they often have changed their email address. > With Github, if they change the email address, they will still be > notified. > - We will get more bug reports and enhancement requests. Although it is > silly, I'm sure many people do not make bug reports because they do > not want to register. Many are already registered on Github. > - Even if our server did not have problems and were running like a > Porsche, why not take more stress from it by moving trac to Github > issues? It creates fewer problems in the future. > - The features repository would be easier to handle and understand. > Everyone could just fork and make branches on their own personal > Github repository. > - Several of our former Git gurus are not around often anymore. Vincent > and Lars would probably come to the rescue if we needed them, but it > would be nice not to have to depend on them. Nothing has really > broken, and whatever setup we're using feels robust to me, but it > still makes me a little worried. > > Despite the benefits
Re: [patch] Theorem environment: set NextNoIndent to 0
On Sat, Feb 18, 2017 at 03:18:59AM -0500, Richard Heck wrote: > On 02/16/2017 04:04 AM, Jürgen Spitzmüller wrote: > > Am Donnerstag, den 16.02.2017, 00:22 -0500 schrieb Scott Kostyshak: > >> Probably the ideal approach is to maximize a weighted average, where > >> the > >> weights are how often the document classes are used. Unfortunately, I > >> don't know how to calculate the weights. > > This would be an application of the IfStyle tag Richard once proposed > > (but never implemented apparently): > > http://marc.info/?l=lyx-devel&m=124967798121429&w=2 > > > > You could use the most frequent setting in the module, and then in the > > diverging classes: > > > > IfStyle Theorem > > NextNoIndent 0 > > End > > This is called "ModifyStyle" now. > > ModifyStyle Theorem > NextNoIndent 0 > End > > Richard > Attached are two patches. The first fixes ParIndent for a few styles. The second implements the NextNoIndent 0. After looking at output from many classes, I do not think a ModifyStyle is needed. I only tested classes that would compile a simple document that contained only standard text and a Theorem environment. If someone thinks it's worth the effort to set up documents (e.g. use as a base our templates) for the other classes, I will do it. As noted in the commit log, hollywood and broadway are strange cases. I attach some sample PDF output from them. I don't plan on thinking of a fix for these. Scott From 086a222ddeb77e47db7d5dccd405a3fdb047845b Mon Sep 17 00:00:00 2001 From: Scott Kostyshak Date: Sun, 19 Feb 2017 18:20:52 -0500 Subject: [PATCH 1/2] Fix ParIndent for various styles --- lib/layouts/g-brief.layout | 4 lib/layouts/g-brief2.layout | 4 lib/layouts/letter.layout | 3 +++ lib/layouts/scrlttr2.layout | 1 + 4 files changed, 12 insertions(+) diff --git a/lib/layouts/g-brief.layout b/lib/layouts/g-brief.layout index 93233aa..abc78f8 100644 --- a/lib/layouts/g-brief.layout +++ b/lib/layouts/g-brief.layout @@ -9,6 +9,10 @@ Input stdinsets.inc Input stdfloats.inc Input stdcounters.inc +ModifyStyle Standard + ParIndent "" +End + Columns 1 Sides 1 PageStyle Empty diff --git a/lib/layouts/g-brief2.layout b/lib/layouts/g-brief2.layout index 9224c78..aa6f5b7 100644 --- a/lib/layouts/g-brief2.layout +++ b/lib/layouts/g-brief2.layout @@ -1024,3 +1024,7 @@ NoStyle Verse # Remove some unwanted styles. # NoStyle Right_Address # NoStyle Address + +ModifyStyle Standard + ParIndent"" +End diff --git a/lib/layouts/letter.layout b/lib/layouts/letter.layout index 382dc6e..53943b2 100644 --- a/lib/layouts/letter.layout +++ b/lib/layouts/letter.layout @@ -17,3 +17,6 @@ Input stdlayouts.inc NoStyle Right_Address NoStyle Address +ModifyStyle Standard + ParIndent "" +End diff --git a/lib/layouts/scrlttr2.layout b/lib/layouts/scrlttr2.layout index da7ab97..de96843 100644 --- a/lib/layouts/scrlttr2.layout +++ b/lib/layouts/scrlttr2.layout @@ -13,6 +13,7 @@ Style Standard LatexName dummy ParSep0.4 AlignPossible Block, Left, Right, Center + ParIndent MM End Input stdlists.inc -- 2.7.4 From 54399c4030d3d8c4bc49d4a44c7b226b77f5d95b Mon Sep 17 00:00:00 2001 From: Scott Kostyshak Date: Fri, 11 Nov 2016 11:55:31 -0500 Subject: [PATCH 2/2] Theorem style: set NextNoIndent to 0 After a Theorem environment, LaTeX does by default indent the following paragraph. I checked various classes and no ModifyStyle was needed. The hollywood and broadway classes are strange cases where there is an indent after the Theorem environment, but it is much smaller than the normal indent. The indent is the same as the opening indent of normal text, which we currently ignore. Further, I don't expect it is common to use theorems in these classes. --- lib/layouts/theorems-ams.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/layouts/theorems-ams.inc b/lib/layouts/theorems-ams.inc index a05b781..c4345be 100644 --- a/lib/layouts/theorems-ams.inc +++ b/lib/layouts/theorems-ams.inc @@ -29,7 +29,7 @@ Style Theorem MarginFirst_Dynamic LatexType Environment LatexName thm - NextNoIndent 1 + NextNoIndent 0 ResetArgs 1 AddToToc thm IsTocCaption 1 -- 2.7.4 broadway.pdf Description: Adobe PDF document hollywood.pdf Description: Adobe PDF document signature.asc Description: PGP signature
Re: doc/attic/it_Customization.lyx compiles with LuaTeX + system fonts on updated TeX Live
On Sun, Feb 19, 2017 at 10:51:24PM +0100, Kornel Benko wrote: > Am Sonntag, 19. Februar 2017 um 16:05:31, schrieb Scott Kostyshak > > > it_Customization.lyx with LuaTeX + system fonts now compiles for me > > without error after updating TeX Live. Can anyone confirm? If so, we can > > apply the attached patch. > > I see the same. From my pov, apply. Pushed at 9fbc73c4. Scott signature.asc Description: PGP signature
Re: git.lyx.org - developers! your ssh public key please
Thanks for the link, Yihui. It is an interesting read. First I want to say that I really don't know much about Git or our current system, so I don't really trust myself on these matters. But that said, I'll give my opinion. I think if everything were already on Github, it would be better. But I think the transition to it would not be trivial. If someone were serious about taking the lead and taking care of *everything* about the transition, then I would personally be in favor of it. If no one steps up to take the lead, then I would not feel comfortable if it were just a few people who all said "yeah I can help a little" because I think things would get stuck in the mud and it would be a mess. I really think we would need someone to lead. I don't think Yihui was volunteering to take the lead. If, however, he were interested (and he should not be, because it would be a burden) in accepting responsibility for everything, I would feel comfortable going forward. This is because I know Yihui's work and trust him as a developer and a person. As for the benefits (i.e., why I would be in favor if to my surprise someone does want to accept responsibility for the transition), I see several benefits: - Patches would not be left to rot. We could easily see in the "pull requests" tab which patches are still pending. - There would be no down time. Our server is having problems. Just yesterday either trac was not working for me or it would take 1 minute to load a ticket. - We don't have to worry about upgrading trac (our 0.12.5 version is based on the 0.12 major version, which was released in June 2010). - An increase in minor contributions. I personally don't think the number of serious, long-time contributors will change as the result of the transition. But I do think that minor patches and "drive-by contributions", and e.g. fixes of typos would increase and I think that minor patches are important and can add up. - We won't have problems with Trac losing all users (one time I think everyone had to re-register). - In trac, it is hard to get a response from a reporter of a bug report from 5 years ago because they often have changed their email address. With Github, if they change the email address, they will still be notified. - We will get more bug reports and enhancement requests. Although it is silly, I'm sure many people do not make bug reports because they do not want to register. Many are already registered on Github. - Even if our server did not have problems and were running like a Porsche, why not take more stress from it by moving trac to Github issues? It creates fewer problems in the future. - The features repository would be easier to handle and understand. Everyone could just fork and make branches on their own personal Github repository. - Several of our former Git gurus are not around often anymore. Vincent and Lars would probably come to the rescue if we needed them, but it would be nice not to have to depend on them. Nothing has really broken, and whatever setup we're using feels robust to me, but it still makes me a little worried. Despite the benefits I list above, I'm not interested in helping with the transition. I don't have much time now, I don't know much about how to do the transition, and I prefer to focus on other things. Thank you for this discussion, Yihui. I always take your opinions very seriously. Scott On Fri, Feb 17, 2017 at 11:26:14AM -0600, Yihui Xie wrote: > Bumping a thread five years later... and just FYI, Python has moved to > Github: https://github.com/python/cpython The story behind the move: > https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ > > I'm not sure if the LyX team knows more about Github or has more > interest now, but I still believe Github is a better choice than > maintaining everything (GIT, Wiki, Trac, and so on) by yourselves, and > you are more likely to attract talents who are willing to contribute > to this project in the future. That said, I'm not as eager as I was > five years ago to convince you guys, since I rarely use LyX or LaTeX > directly now (but LyX is still *the* best frontend for LaTeX in my > mind). If there is an intention to move, great, and let me know if > there is anything I can help, otherwise it is totally fine, too. > Disclaimer: I'm not affiliated with Github in any sense. I'm just an > ordinary user who happens to have benefited a lot from it when > developing open source software. > > Regards, > Yihui > -- > https://yihui.name > > > On Fri, Mar 2, 2012 at 9:25 PM, Yihui Xie wrote: > > Well, I think I understand some of the advantages of GIT like easy > > branching. I do not even bother to compare it to SVN because GIT is so > > much better. > > > > I mean GitHub makes GIT even better; there are too many advantages and > > I just list a few of them here: > > > > 1. developers manage their own SSH keys on GitHub and you do not need > > to ask them to s
Re: doc/attic/it_Customization.lyx compiles with LuaTeX + system fonts on updated TeX Live
Am Sonntag, 19. Februar 2017 um 16:05:31, schrieb Scott Kostyshak > it_Customization.lyx with LuaTeX + system fonts now compiles for me > without error after updating TeX Live. Can anyone confirm? If so, we can > apply the attached patch. I see the same. From my pov, apply. Kornel signature.asc Description: This is a digitally signed message part.
doc/attic/it_Customization.lyx compiles with LuaTeX + system fonts on updated TeX Live
it_Customization.lyx with LuaTeX + system fonts now compiles for me without error after updating TeX Live. Can anyone confirm? If so, we can apply the attached patch. From 35cbd5ed87bc6a715789adbce40a67361b84b483 Mon Sep 17 00:00:00 2001 From: Scott Kostyshak Date: Sun, 19 Feb 2017 16:04:43 -0500 Subject: [PATCH] ctests: it_Customization_pdf5_systemF now compiles Thanks to an update in TeX Live. --- development/autotests/invertedTests | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/development/autotests/invertedTests b/development/autotests/invertedTests index c7117f3..b02b0a8 100644 --- a/development/autotests/invertedTests +++ b/development/autotests/invertedTests @@ -257,7 +257,7 @@ export/doc/attic/eu_UserGuide_pdf[25].* # Files in the attic with non-default output # (i.e. could be ERT, package incompatiblity, ...) -export/doc/attic/it_(Customization_pdf5|UserGuide_dvi3|UserGuide_pdf4)_systemF +export/doc/attic/it_(UserGuide_dvi3|UserGuide_pdf4)_systemF export/doc/attic/sk_UserGuide_pdf4_texF export/doc/attic/id_UserGuide_.*systemF -- 2.7.4 signature.asc Description: PGP signature
Re: CopyrightYear is the correct command name in acmsiggraph-0.92.layout
Am Sonntag, den 19.02.2017, 11:12 +0100 schrieb Jean-Pierre Chrétien: > OK, that's clear now, it works, thanks for the hint. I pushed the fix to master. Richard, this should also go to branch. Jürgen signature.asc Description: This is a digitally signed message part
Re: CopyrightYear is the correct command name in acmsiggraph-0.92.layout
Le 18/02/2017 à 19:19, Jürgen Spitzmüller a écrit : Am Samstag, den 18.02.2017, 18:37 +0100 schrieb Jean-Pierre Chrétien: Did your commit really solve this issue ? I'm not sure to understand the added code. Yes. Try the attached patch. OK, that's clear now, it works, thanks for the hint. -- Jean-Pierre