Re: Standalone Math Editor

[Wei-Ting Lin]

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

[Scott Kostyshak]

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 

Re: git.lyx.org - developers! your ssh public key please

[Yihui Xie]

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

Re: [patch] Theorem environment: set NextNoIndent to 0

[Scott Kostyshak]

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=124967798121429=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

[Scott Kostyshak]

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

[Scott Kostyshak]

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
> 

Re: doc/attic/it_Customization.lyx compiles with LuaTeX + system fonts on updated TeX Live

[Kornel Benko]

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

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

[Jürgen Spitzmüller]

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

[Jean-Pierre Chrétien]

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