Re: [LyX master] Add support for stmaryrd.sty (bug #8434)

[Jürgen Spitzmüller]

Am Samstag 15 Dezember 2012, 13:10:34 schrieb Georg Baum:
 commit f67cf6f4bb3e3d22ac9aebfa22027c3537cbdf61
 Author: Georg Baum b...@lyx.org
 Date:   Sat Dec 15 13:02:40 2012 +0100
 
 Add support for stmaryrd.sty (bug #8434)

development/FORMAT not updated.

Jürgen

Re: [LyX master] Add script for automatic toolbar image creation.

[Kornel Benko]

Am Sonntag, 16. Dezember 2012 um 14:44:22, schrieb Georg Baum b...@lyx.org
 The branch, master, has been updated.
 
 - Log -
 
 commit 8838648858532a8f1c323f25f37a72c4d2eba496
 Author: Georg Baum b...@lyx.org
 Date:   Sun Dec 16 14:38:21 2012 +0100
 
 Add script for automatic toolbar image creation.
 
 Manually created toolbar images are needed in many cases, but for simple
 symbols automatically generated ones are better than nothing.
 

Do you plan to add the created images to git?

If I call the script, I get 757 .png files. But I have problems with the data.

1.) in our lib/images/math are only 530 images.
2.) If I compare the newly created images with the git-ones,
a.) I see they are 409 binary different
b.)   totally new 348 files
c.)   121 files only in lib/images/math

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [DECISION] final layout patches for branch

[Richard Heck]

On 12/13/2012 06:32 PM, Uwe Stöhr wrote:

Am 10.12.2012 18:59, schrieb Richard Heck:

So what does my change break?

Here's my problem: If we do things as you propose, then we have 
different layout files with the same

name under 2.0.5 and 2.0.6.


I understand your point. But as said, who really downgrades from a 
working LyX 2.0.6 to 2.0.5?


I think this question has been answered. The worry isn't so much that 
people downgrade (though they do, if a new version introduces a bug that 
really bothers them). It's rather that people often use several 
machines, and those machines may not have the same LyX version on them. 
I keep my main machine at home very up to date, for example, but not 
always my laptop or even my work computer. Let alone my wife's Mac, 
which I might use on a trip. This is very normal.


We in the past always added styles to layouts because our major 
releases only take place every 2 years while the document class 
progress is much faster.
Please have a look of the layout file changes during the 2.0.x cycle. 
It was not only me who added a style to layouts, others did that as 
well and for scientific classes we will have to do it anyway for the 
reasons I stated.
But as this issue is so fundamental, I request that you bring this to 
the users list and decide then.



Feel free to start a discussion on the user list.


So people using two different minor versions on two different machines
will find that a single document won't even load properly on the 
older version. And that passing it back and forth between the two 
causes all kinds of problems. Specifically, files created with the 
new ACM and europecv layouts will not load properly in 2.0.5.


- the changes for europeCV are cosmetic ones: I only added styles for 
things one currently has to specify in the preamble. I can retract my 
patch for this document class.


This looks to me like almost a format change. When we do this kind of 
thing, we should have lyx2lyx that will find the stuff previously in the 
preamble and convert it. I think Jurgen has just done this for some 
things in beamer.


- for ACM we will have no other choice because your paper won't be 
accepted for submission without the new styles. So if you reject my 
patch for ACM, you force users to read the submission guidelines after 
they notice that their submission was rejected. They will then find 
out that they will have to add things as ERT. (But only experiences 
users know how to handle ERT.) Is this our aim?



My proposal is to ship the new layout, but with a new, versioned name.


I'm opposed to this, see my arguments in the new thread I started.


I'll respond to that separately, though see below.

For the document class files: I state it the last time: You have to 
fulfill the submission guidelines. The journals don't care of your 
OS and versions. If you don't fulfill the guidelines, you won't be 
accepted, point!


Yes, but you are assuming something that does not seem evident, 
namely: that everyone who is using these class files is doing so 
because they are planning to submit their paper to a journal that 
uses that class file.


Of course, because that is what these document classes and thus our 
layouts are designed for.


They may be designed for it, but, as many people have said, that just 
doesn't imply that that is always what they are used for. As people have 
pointed out in the APA6 thread, the APA classes get used for thesis 
formats by some universities or departments. It would not surprise me if 
there were similar examples involving the journal classes, especially 
ones that have to do with conferences. Maybe some obscure journal uses 
the ACM class, and it's sticking with the older one for now. Do we know 
this is not true? Or what if I am running a conference and I've said we 
want submissions using such and such a class? Am I going to change that 
just because someone has decided to release an update to that class? 
Maybe so, and maybe not.


As I've said, as long as the updated layout classes are available, 
people can use them. I just don't see the point of breaking a bunch of 
other stuff to make that very slightly easier.


That is not true. People have old files that got rejected, but they 
keep them in
that format anyway. Those files should not stop working because they 
upgraded LyX.


As I stated, except of the case with Springer old files keep 
compilable. None of may changes break the compilation of existing 
files. Also pre-prints, editor notes, etc. work fine.


Unless I'm mistaken, they do break compilation, because the LaTeX files 
that we output will not compile with older versions of the class files. 
Yes, I understand that, with the journal layouts, this will not be an 
issue for most people who are using them, because they will have to 
upgrade to the most recent version in order to submit their papers to 
certain journals. But this is not the only use case.


I'll continue this in the other thread.

Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

[Richard Heck]

On 12/13/2012 05:45 PM, Uwe Stöhr wrote:

Dear colleagues,

sorry for the delay, but my spare time is currently very limited.
Before I will comment on the different posts in the old thread I want 
to summarize what we are discussing about because the old thread is a 
mixture of different topics and misunderstandings.


Thank you for summarizing your concerns. I'll respond to a few of them, 
then summarize mine.



The different points are:

1. backward compatibility
I'm not opposed to provide backward compatibility in general. That's 
why I always invested a lot of time in lyx2lyx code, see my commits 
for the InsetArgument stuff. However, I think that we should be 
flexible enough to make changes to layouts to keep them compilable 
with the latest version of a document class. (It is a very rare case 
that this breaks forward compatibility and modernCV is such a case, 
but let's discuss this in another thread).
The point is to be user friendly. My experience is that people expect 
an up to date example/template file. Before starting to write e.g. a 
paper many users update their software and then try to keep it 
untouched until the paper is accepted. So we can expect that a 
non-negligible amount of users will be confronted with an updated 
document class or submission guideline. The strength of LyX in my 
opinion is that it helps you in the workflow such that you are not 
forced to step through the submission guidelines in detail but can 
start writing a paper. So having an up to date example/template file 
is very useful. This might require to add a style in a layout file but 
this is no problem as long as you still can compile your existing LyX 
files with it.


Perhaps I am reading too much into this, but if your main concern is the 
example or template file, then there is no issue here. I have already 
said that I have no objection to making the example and template files 
be up to date, in the sense that they use the updated layout. It's just 
that this layout will have a new name. So this is not an issue.



2. scientific document classes
As a submitter you will have to follow always the latest submission 
guidelines. So having an outdated example/template file would be 
frustrating for the users if they wonder why the submission systems 
reject the TeX-files created with LyX. OK, we could add required new 
styles as ERT but this is in my opinion not user-friendly and opposed 
to the goal of LyX not to confront the user with evil things. To 
fulfill the submission guidelines you will in any case have to use the 
latest version of the document class for your journal so we don't do 
anything wrong to keep the layout files for scientific classes up to 
date.


If this is about the template, then again there is no issue here: It can 
use the updated layout. And this will make it easier for inexperienced 
users to choose the right layout, since they will very often start with 
the template.



3. my LaTeX system is too old
This topic is something I don't understand that we even discuss about 
it. I mean where do we cut the line what we require? Everybody of us 
developers added some styles to layout files and that would break the 
compilation if you have a very old LaTeX installation. Take for 
example the case of the latest additions to KOMA-script made by 
Jürgen. These styles support commands in KOMA-script that are in 
recent TeX distributions, but for example not in the old teTeX 3. So a 
user might complain about that. But I think you would agree that we 
don't rely anymore on teTeX but on e.g. TeXLive. However, there are 
many TeXLive versions around and users could e.g. use TeXLive 2011 but 
with recent document classes (installed manually or by TeXLive's 
update mechanism). MiKTeX users will in most cases use always the 
latest package versions.
Our aim is platform in dependency so the only thing we can do to 
please all users, no matter what OS and TeX-distribution they use, we 
have to assure that the latest package version is compliable with the 
layouts we provide. I agree that we should try to keep old documents 
compilable and we could do so in the past (except for e.g. Springer). 
If users encounter problems, they can update the corresponding 
LaTeX-package and it will work again while users using the latest 
Package version cannot downgrade and downgrading is for example with 
MiKTeX and also TeXLive (at least on Windows) not possible.
So if the compilability requires a layout file change, we should do 
that and announce that in the release notes. Otherwise our layouts 
will become more and more less useful with the time and from a user's 
point of view it is incomprehensible why LyX would only update layouts 
every 2 years with a new major LyX version.
In general note that if we got bug reports in e.g. LyX 1.6.8 in our 
bugtracker or the mailing lists we tell the users to update LyX. The 
same is expected by the TeX package authors.


Obviously, there are extreme cases we cannot 

Re: An idea on improving the literate programming support

[Yihui Xie]

If the only goal is to edit R code externally, it is already possible
with knitr: http://yihui.name/knitr/demo/externalization/

And a general solution of sending program code to the terminal might
be more useful.

Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Dec 16, 2012 at 6:14 AM, Liviu Andronic landronim...@gmail.com wrote:
 On Thu, Dec 13, 2012 at 8:04 PM, Scott Kostyshak skost...@lyx.org wrote:
 I wonder if this ticket has something to say about implementation:
 http://www.lyx.org/trac/ticket/7404
 If each inset had an option to edit externally then the user could
 set the edit command to whatever he/she wanted.

 I'm not sure that this would work. For one, this would imply that each
 chunk is opened in a different R session, which is suboptimal.

 Yihui's idea could prove immensely useful, but we need a document-wide
 solution. Here's a half-baked proposal for implementation:
 - Define an 'Sweave load workspace' custom inset that would allow to
 echo=F=
 load('workspace')
 @

 where 'workspace' can be './.RData' or whatever the user inputs.
 Given Juergen's recent work on insets, I think it is possible to
 define such a monstrosity.

 - In the c-menu of this inset, there would be an 'Open R session' item
 that when activated would open a terminal in the dir of the LyX file,
 and load the associated workspace (as indicated in the inset). If
 possible, instead of a terminal we would open RStudio (or some other R
 editor).

 - We would need a new LFUN (associated with some 'ctrl+alt+r' binding
 or whatever) that would allow the execution of chunk: Take the chunk
 contents and pass them to R (or RStudio). We might want to have an
 LFUN allowing executing code line by line. Such an arrangement would
 allow to evaluate the chunks while working in LyX.

 - Another possibility would be that upon activating the c-menu item,
 LyX would export to Sweave, open the resulting .Rnw file in RStudio
 and let the user use RStudio functionality to evaluate the chunks.

 Would it be difficult to implement something similar?

 Regards
 Liviu

Re: [LyX master] Add support for stmaryrd.sty (bug #8434)

[Jürgen Spitzmüller]

Am Samstag 15 Dezember 2012, 13:10:34 schrieb Georg Baum:
> commit f67cf6f4bb3e3d22ac9aebfa22027c3537cbdf61
> Author: Georg Baum 
> Date:   Sat Dec 15 13:02:40 2012 +0100
> 
> Add support for stmaryrd.sty (bug #8434)

development/FORMAT not updated.

Jürgen

Re: [LyX master] Add script for automatic toolbar image creation.

[Kornel Benko]

Am Sonntag, 16. Dezember 2012 um 14:44:22, schrieb Georg Baum 
> The branch, master, has been updated.
> 
> - Log -
> 
> commit 8838648858532a8f1c323f25f37a72c4d2eba496
> Author: Georg Baum 
> Date:   Sun Dec 16 14:38:21 2012 +0100
> 
> Add script for automatic toolbar image creation.
> 
> Manually created toolbar images are needed in many cases, but for simple
> symbols automatically generated ones are better than nothing.
> 

Do you plan to add the created images to git?

If I call the script, I get 757 .png files. But I have problems with the data.

1.) in our lib/images/math are only 530 images.
2.) If I compare the newly created images with the git-ones,
a.) I see they are 409 binary different
b.)   totally new 348 files
c.)   121 files only in lib/images/math

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [DECISION] final layout patches for branch

[Richard Heck]

On 12/13/2012 06:32 PM, Uwe Stöhr wrote:

Am 10.12.2012 18:59, schrieb Richard Heck:

So what does my change break?

Here's my problem: If we do things as you propose, then we have 
different layout files with the same

name under 2.0.5 and 2.0.6.


I understand your point. But as said, who really downgrades from a 
working LyX 2.0.6 to 2.0.5?


I think this question has been answered. The worry isn't so much that 
people downgrade (though they do, if a new version introduces a bug that 
really bothers them). It's rather that people often use several 
machines, and those machines may not have the same LyX version on them. 
I keep my main machine at home very up to date, for example, but not 
always my laptop or even my work computer. Let alone my wife's Mac, 
which I might use on a trip. This is very normal.


We in the past always added styles to layouts because our major 
releases only take place every 2 years while the document class 
progress is much faster.
Please have a look of the layout file changes during the 2.0.x cycle. 
It was not only me who added a style to layouts, others did that as 
well and for scientific classes we will have to do it anyway for the 
reasons I stated.
But as this issue is so fundamental, I request that you bring this to 
the users list and decide then.



Feel free to start a discussion on the user list.


So people using two different minor versions on two different machines
will find that a single document won't even load properly on the 
older version. And that passing it back and forth between the two 
causes all kinds of problems. Specifically, files created with the 
new ACM and europecv layouts will not load properly in 2.0.5.


- the changes for europeCV are cosmetic ones: I only added styles for 
things one currently has to specify in the preamble. I can retract my 
patch for this document class.


This looks to me like almost a format change. When we do this kind of 
thing, we should have lyx2lyx that will find the stuff previously in the 
preamble and convert it. I think Jurgen has just done this for some 
things in beamer.


- for ACM we will have no other choice because your paper won't be 
accepted for submission without the new styles. So if you reject my 
patch for ACM, you force users to read the submission guidelines after 
they notice that their submission was rejected. They will then find 
out that they will have to add things as ERT. (But only experiences 
users know how to handle ERT.) Is this our aim?



My proposal is to ship the new layout, but with a new, versioned name.


I'm opposed to this, see my arguments in the new thread I started.


I'll respond to that separately, though see below.

For the document class files: I state it the last time: You have to 
fulfill the submission guidelines. The journals don't care of your 
OS and versions. If you don't fulfill the guidelines, you won't be 
accepted, point!


Yes, but you are assuming something that does not seem evident, 
namely: that everyone who is using these class files is doing so 
because they are planning to submit their paper to a journal that 
uses that class file.


Of course, because that is what these document classes and thus our 
layouts are designed for.


They may be designed for it, but, as many people have said, that just 
doesn't imply that that is always what they are used for. As people have 
pointed out in the APA6 thread, the APA classes get used for thesis 
formats by some universities or departments. It would not surprise me if 
there were similar examples involving the journal classes, especially 
ones that have to do with conferences. Maybe some obscure journal uses 
the ACM class, and it's sticking with the older one for now. Do we know 
this is not true? Or what if I am running a conference and I've said we 
want submissions using such and such a class? Am I going to change that 
just because someone has decided to release an update to that class? 
Maybe so, and maybe not.


As I've said, as long as the updated layout classes are available, 
people can use them. I just don't see the point of breaking a bunch of 
other stuff to make that very slightly easier.


That is not true. People have old files that got rejected, but they 
keep them in
that format anyway. Those files should not stop working because they 
upgraded LyX.


As I stated, except of the case with Springer old files keep 
compilable. None of may changes break the compilation of existing 
files. Also pre-prints, editor notes, etc. work fine.


Unless I'm mistaken, they do break compilation, because the LaTeX files 
that we output will not compile with older versions of the class files. 
Yes, I understand that, with the journal layouts, this will not be an 
issue for most people who are using them, because they will have to 
upgrade to the most recent version in order to submit their papers to 
certain journals. But this is not the only use case.


I'll continue this in the other thread.

Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

[Richard Heck]

On 12/13/2012 05:45 PM, Uwe Stöhr wrote:

Dear colleagues,

sorry for the delay, but my spare time is currently very limited.
Before I will comment on the different posts in the old thread I want 
to summarize what we are discussing about because the old thread is a 
mixture of different topics and misunderstandings.


Thank you for summarizing your concerns. I'll respond to a few of them, 
then summarize mine.



The different points are:

1. backward compatibility
I'm not opposed to provide backward compatibility in general. That's 
why I always invested a lot of time in lyx2lyx code, see my commits 
for the InsetArgument stuff. However, I think that we should be 
flexible enough to make changes to layouts to keep them compilable 
with the latest version of a document class. (It is a very rare case 
that this breaks forward compatibility and modernCV is such a case, 
but let's discuss this in another thread).
The point is to be user friendly. My experience is that people expect 
an up to date example/template file. Before starting to write e.g. a 
paper many users update their software and then try to keep it 
untouched until the paper is accepted. So we can expect that a 
non-negligible amount of users will be confronted with an updated 
document class or submission guideline. The strength of LyX in my 
opinion is that it helps you in the workflow such that you are not 
forced to step through the submission guidelines in detail but can 
start writing a paper. So having an up to date example/template file 
is very useful. This might require to add a style in a layout file but 
this is no problem as long as you still can compile your existing LyX 
files with it.


Perhaps I am reading too much into this, but if your main concern is the 
example or template file, then there is no issue here. I have already 
said that I have no objection to making the example and template files 
be up to date, in the sense that they use the updated layout. It's just 
that this layout will have a new name. So this is not an issue.



2. scientific document classes
As a submitter you will have to follow always the latest submission 
guidelines. So having an outdated example/template file would be 
frustrating for the users if they wonder why the submission systems 
reject the TeX-files created with LyX. OK, we could add required new 
styles as ERT but this is in my opinion not user-friendly and opposed 
to the goal of LyX not to confront the user with "evil" things. To 
fulfill the submission guidelines you will in any case have to use the 
latest version of the document class for your journal so we don't do 
anything wrong to keep the layout files for scientific classes up to 
date.


If this is about the template, then again there is no issue here: It can 
use the updated layout. And this will make it easier for inexperienced 
users to choose the right layout, since they will very often start with 
the template.



3. "my LaTeX system is too old"
This topic is something I don't understand that we even discuss about 
it. I mean where do we cut the line what we require? Everybody of us 
developers added some styles to layout files and that would break the 
compilation if you have a very old LaTeX installation. Take for 
example the case of the latest additions to KOMA-script made by 
Jürgen. These styles support commands in KOMA-script that are in 
recent TeX distributions, but for example not in the old teTeX 3. So a 
user might complain about that. But I think you would agree that we 
don't rely anymore on teTeX but on e.g. TeXLive. However, there are 
many TeXLive versions around and users could e.g. use TeXLive 2011 but 
with recent document classes (installed manually or by TeXLive's 
update mechanism). MiKTeX users will in most cases use always the 
latest package versions.
Our aim is platform in dependency so the only thing we can do to 
please all users, no matter what OS and TeX-distribution they use, we 
have to assure that the latest package version is compliable with the 
layouts we provide. I agree that we should try to keep old documents 
compilable and we could do so in the past (except for e.g. Springer). 
If users encounter problems, they can update the corresponding 
LaTeX-package and it will work again while users using the latest 
Package version cannot downgrade and downgrading is for example with 
MiKTeX and also TeXLive (at least on Windows) not possible.
So if the compilability requires a layout file change, we should do 
that and announce that in the release notes. Otherwise our layouts 
will become more and more less useful with the time and from a user's 
point of view it is incomprehensible why LyX would only update layouts 
every 2 years with a new major LyX version.
In general note that if we got bug reports in e.g. LyX 1.6.8 in our 
bugtracker or the mailing lists we tell the users to update LyX. The 
same is expected by the TeX package authors.


Obviously, there are extreme cases we cannot 

Re: An idea on improving the literate programming support

[Yihui Xie]

If the only goal is to edit R code externally, it is already possible
with knitr: http://yihui.name/knitr/demo/externalization/

And a general solution of sending program code to the terminal might
be more useful.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Dec 16, 2012 at 6:14 AM, Liviu Andronic  wrote:
> On Thu, Dec 13, 2012 at 8:04 PM, Scott Kostyshak  wrote:
>> I wonder if this ticket has something to say about implementation:
>> http://www.lyx.org/trac/ticket/7404
>> If each inset had an option to "edit externally" then the user could
>> set the "edit command" to whatever he/she wanted.
>>
> I'm not sure that this would work. For one, this would imply that each
> chunk is opened in a different R session, which is suboptimal.
>
> Yihui's idea could prove immensely useful, but we need a document-wide
> solution. Here's a half-baked proposal for implementation:
> - Define an 'Sweave load workspace' custom inset that would allow to
>