Re: Solution: Summary for the Win installer problem

Am 07.03.2018 um 16:17 schrieb Uwe Stöhr: I am going nuts. MiKTeX released now some fixes to its package handling but they arrived broken on the package servers. Therefore since today the solution we found for LyX in combination with MiKTeX doesn't work. This was not correct. In fact M

Re: Solution: Summary for the Win installer problem

ose their personal settings. With the version 3 of the installer I think we found the best possible solution where people can kep their settings and get a working LyX. I think that explaining people how to install LaTeX themselves is the way to go. My experience (even at the university

Re: Solution: Summary for the Win installer problem

Am 07.03.2018 um 17:27 schrieb Uwe Stöhr: I must admit that I haven't tested the "never" case for a long time. I tested this now and the installer correctly respects the setting "never". So never means never. You don't get any updates nor packages if you really don't want this. Configuring L

Re: Solution: Summary for the Win installer problem

use stable and older version. Is there some *full* MikTex/TeXlive installation bundle for Windows which is stable? If yes how big is it in terms of MB/GB? Would it significantly increase our current installer-bundle? I also do not propose this as 2.3.0 solution but it seems conceptually wrong that

Re: Solution: Summary for the Win installer problem

Le 07/03/2018 à 17:27, Uwe Stöhr a écrit : In general: I have no problem in being criticized. But I have a problem that I am talking directly to the MiKTeX developer to find a solution and when I do what he proposes you are telling me that it can be done better. I think you are indeed the

Re: Solution: Summary for the Win installer problem

Am 06.03.2018 um 16:37 schrieb Jean-Marc Lasgouttes: In general: I have no problem in being criticized. But I have a problem that I am talking directly to the MiKTeX developer to find a solution and when I do what he proposes you are telling me that it can be done better. The goal is

Re: Solution: Summary for the Win installer problem

day, I will create a new installer, if not, let's > > release LyX 2.3.0 with the installer version 3 I linked above. > > I am going nuts. MiKTeX released now some fixes to its package handling but > they arrived broken on the package servers. Therefore since today the > solut

Re: Solution: Summary for the Win installer problem

to test different > > installations, update states etc. to find a solution. > > I understand how frustrating the thing can be. But working alone on this is > probably the source of many issues. It is never good to have an own niche > where only one voice counts. We are a team, and this is

Re: Solution: Summary for the Win installer problem

n 3 I linked above. I am going nuts. MiKTeX released now some fixes to its package handling but they arrived broken on the package servers. Therefore since today the solution we found for LyX in combination with MiKTeX doesn't work. I am sorry to say that I need to wait another day

Re: Solution: Summary for the Win installer problem

On Tue, Mar 06, 2018 at 01:44:38PM +, Uwe Stöhr wrote: > Here is my last attempt to explain the situation. Then I will be quiet I hope that we can continue this discussion. Specifically, I think the proposal to give a message and ask the user is reasonable. Thanks for all of your time on this

Re: Solution: Summary for the Win installer problem

r you accept my solution or you have no windows installer". Here are the principal use cases for LyX users: A: I am a happy user of LyX 2.2.x and are not interested to upgrade anything. If I get now a document from a colleague containing a LaTeX package I don't have yet installed, MiKTeX

Re: Solution: Summary for the Win installer problem

the document. To be able to install the missing package, it needs to update its package handling system. Due to a bug this update can break LaTeX completely and the user is lost. None of his LyX document will be compilable anymore. The only solution for him is to reinstall MiKTeX and he loose

Re: Solution: Summary for the Win installer problem

On 03/05/2018 07:33 PM, Uwe Stöhr wrote: > Am 05.03.2018 um 23:46 schrieb Richard Heck: > >> Uwe, even if LyX will not work without the updated installation, we >> CANNOT update the user's LaTeX installation without asking for >> permission---which means giving them the option to cancel the entire

Re: Solution: Summary for the Win installer problem

Am 05.03.2018 um 23:46 schrieb Richard Heck: Uwe, even if LyX will not work without the updated installation, we CANNOT update the user's LaTeX installation without asking for permission---which means giving them the option to cancel the entire install. Otherwise, we can break things, as in the

Re: Solution: Summary for the Win installer problem

On 03/05/2018 03:18 PM, racoon wrote: > On 05.03.2018 20:16, Uwe Stöhr wrote: >> Am 05.03.2018 um 19:37 schrieb racoon: >> >>> However, it does not give the user a choice on whether to update >>> MiKTeX or not. >> >> Yes, that is correct and I explained now in several mails why and >> that there is

Re: Solution: Summary for the Win installer problem

On 05.03.2018 20:16, Uwe Stöhr wrote: Am 05.03.2018 um 19:37 schrieb racoon: However, it does not give the user a choice on whether to update MiKTeX or not. Yes, that is correct and I explained now in several mails why and that there is no other option. Sorry, I have a bit of a hard time f

Re: Solution: Summary for the Win installer problem

Am 05.03.2018 um 19:37 schrieb racoon: However, it does not give the user a choice on whether to update MiKTeX or not. Yes, that is correct and I explained now in several mails why and that there is no other option. Also, I noticed that the MiKTeX Package Manager opens up for some reason a

Re: Solution: Summary for the Win installer problem

On 05.03.2018 19:37, racoon wrote: On 04.03.2018 19:36, Uwe Stöhr wrote: Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to check if th

Re: Solution: Summary for the Win installer problem

On 04.03.2018 19:36, Uwe Stöhr wrote: Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to check if this will work for all cases. OK, I

Re: Solution: Summary for the Win installer problem

Le 04/03/2018 à 22:23, Uwe Stöhr a écrit : We need to install packages (hyphenation, language support, tipa, math, etc.) because we cannot know what features will be used by the user. This can only be done if the user has a working package handling system. As user I expect a working software an

Re: Solution: Summary for the Win installer problem

On Sun, Mar 04, 2018 at 06:36:54PM +, Uwe Stöhr wrote: > Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: > > > Good news: There will be a new MiKTeX installer soon and the MiKTeX > > maintainer proposed a workaround for the main bug. I cannot promise that > > I will find time today to check if this

Re: Solution: Summary for the Win installer problem

Am 04.03.2018 um 18:59 schrieb Jean-Marc Lasgouttes: So I install texlive with the medium size install Sure, but to do this you need Internet access. Having to wait until I actually use LyX to decide what packages to install would be a recipe for failure. Again, the problem I had is not a

Re: Solution: Summary for the Win installer problem

Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to check if this will work for all cases. OK, I could check it and it works. The new i

Re: Solution: Summary for the Win installer problem

Le 04/03/2018 à 17:22, Uwe Stöhr a écrit : A fully functional LyX is impossible without Internet connection because missing LaTeX packages must be installed via Internet. There is no difference between TeXLive and MiKTeX in this respect. (polemic:  Let's look around, even in poor countries lik

Re: Solution: Summary for the Win installer problem

On Sun, Mar 04, 2018 at 03:19:40PM +, Uwe Stöhr wrote: > Am 04.03.2018 um 00:32 schrieb Uwe Stöhr: > > > As soon there is a new MiKTeX installer available I will release another > > installer > > Good news: There will be a new MiKTeX installer soon and the MiKTeX > maintainer proposed a worka

Re: Solution: Summary for the Win installer problem

it is not easy to find a solution. Yes, TeXLive users are not affected. I explained the problematic as best as I can. Now please let me get a proper solution ready together with the MiKTeX maintainer. What happens in both the case of the installer and the bundle if a user installs LyX without

Re: Solution: Summary for the Win installer problem

On Sat, Mar 03, 2018 at 11:32:23PM +, Uwe Stöhr wrote: > Am 02.03.2018 um 20:16 schrieb Uwe Stöhr: > > > - Conclusion: I cannot do more right now to wait until MiKTeX releases > > the fixes  for the 2 bugs. > > Here is the solution in form of a new instal

Re: Solution: Summary for the Win installer problem

Am 04.03.2018 um 00:32 schrieb Uwe Stöhr: As soon there is a new MiKTeX installer available I will release another installer Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to

Solution: Summary for the Win installer problem

Am 02.03.2018 um 20:16 schrieb Uwe Stöhr: - Conclusion: I cannot do more right now to wait until MiKTeX releases the fixes  for the 2 bugs. Here is the solution in form of a new installer: http://ftp.lyx.de/LyXWinInstaller/LyX2.3.0/ I don't want to write pages to describe the problemat

Re: [PATCH] Handle Solution* in lyx2lyx

On 11/28/2015 09:56 PM, Uwe Stöhr wrote: > Am 28.11.2015 um 04:46 schrieb Richard Heck: > >> Sorry, please try the attached. > > Many thanks. > > I could not apply them or I made a mistake. > I therefore took some of your code and put it in. > > In your patch was a mistake because for the starred v

Re: [PATCH] Handle Solution* in lyx2lyx

pagestyle default \tracking_changes false \output_changes false \html_math_output 0 \html_css_as_file 0 \html_be_strict false \end_header \begin_body \begin_layout Standard test \end_layout \begin_layout Solution* solution* \end_layout \begin_layout Standard - \end_layout \begin_layout Exercise* excercise* \end_layout \begin_layout Solution solution \end_layout \begin_layout Standard -

Re: [patch] support for 'solution' in theorems

On 11/28/2015 02:44 PM, Uwe Stöhr wrote: > Am 28.11.2015 um 04:58 schrieb Richard Heck: > >> Yes, well, we have had that discussion, and you know how it went. > > I know. And you know that I did nt forget solution* purposely. Of course. >> And honestly, it is not that

Re: [patch] support for 'solution' in theorems

Am 28.11.2015 um 04:58 schrieb Richard Heck: Yes, well, we have had that discussion, and you know how it went. I know. And you know that I did nt forget solution* purposely. And honestly, it is not that hard to write reversion code. For me it is. That is the part of a new feature that

Re: [patch] support for 'solution' in theorems

Uwe Stöhr wrote: > Guys, please! If you find a problem then shout but not if there is no > real problem. Jürgen reviewed my proposal, I did a lot of tests and > waited until alpha 1 is released upon request of Scott. For the third time: Unless it was done in private communication, there was _no_

Re: [patch] support for 'solution' in theorems

On 11/27/2015 10:10 PM, Uwe Stöhr wrote: > Am 28.11.2015 um 03:48 schrieb Richard Heck: > >> I found a bug: You forgot to revert Solution* in the lyx2lyx code. It >> was completely accidental that I found this, too. > > OK, but this is no reason to stop shipping alpha2. A

Re: [PATCH] Handle Solution* in lyx2lyx

On 11/27/2015 10:01 PM, Uwe Stöhr wrote: > Am 27.11.2015 um 23:06 schrieb Richard Heck: > >> The attached patch corrects an oversight in the lyx2lyx code for the >> Solution and Solution* environments, namely, that the latter was not >> handled. Someone please have a look.

Re: [patch] support for 'solution' in theorems

Am 28.11.2015 um 03:48 schrieb Richard Heck: I found a bug: You forgot to revert Solution* in the lyx2lyx code. It was completely accidental that I found this, too. OK, but this is no reason to stop shipping alpha2. And you know my opinion about reverting new features to TeX code. If I could

Re: [PATCH] Handle Solution* in lyx2lyx

Am 27.11.2015 um 23:06 schrieb Richard Heck: The attached patch corrects an oversight in the lyx2lyx code for the Solution and Solution* environments, namely, that the latter was not handled. Someone please have a look. And Uwe, can you please test? Your patch is not applicable. You have

Re: [patch] support for 'solution' in theorems

there is no > real problem. Jürgen reviewed my proposal, I did a lot of tests and > waited until alpha 1 is released upon request of Scott. > > > Would you recommend I stop the release of alpha2? > > Sorry, but this is ridiculous. Nobody found a bug. I found a bug: You

Re: [patch] support for 'solution' in theorems

Am 27.11.2015 um 18:55 schrieb Georg Baum: I don't know if there are problems (apart from the copy-paste error found by Guillaume)... Guys, please! If you find a problem then shout but not if there is no real problem. Jürgen reviewed my proposal, I did a lot of tests and waited until alpha 1

[PATCH] Handle Solution* in lyx2lyx

The attached patch corrects an oversight in the lyx2lyx code for the Solution and Solution* environments, namely, that the latter was not handled. Someone please have a look. And Uwe, can you please test? I've tested it myself, and it seems to work here. I am thinking seriously at this

Re: [patch] support for 'solution' in theorems

On 11/27/2015 02:08 PM, Scott Kostyshak wrote: > On Fri, Nov 27, 2015 at 08:00:53PM +0100, Georg Baum wrote: >> Scott > Kostyshak wrote: >> >>> Oops. I take responsibility for this for releasing with unreviewed >>> stuff. Would you recommend I stop the release of alpha2? >> >> No IMHO, since tarba

Re: [patch] support for 'solution' in theorems

On Fri, Nov 27, 2015 at 08:00:53PM +0100, Georg Baum wrote: > Scott Kostyshak wrote: > > > Oops. I take responsibility for this for releasing with unreviewed > > stuff. Would you recommend I stop the release of alpha2? > > No IMHO, since tarballs have already been published, this would only cause

Re: [patch] support for 'solution' in theorems

Scott Kostyshak wrote: > Oops. I take responsibility for this for releasing with unreviewed > stuff. Would you recommend I stop the release of alpha2? No IMHO, since tarballs have already been published, this would only cause confusion. The probability that something is wrong is low (but not zer

Re: [patch] support for 'solution' in theorems

On Fri, Nov 27, 2015 at 06:55:52PM +0100, Georg Baum wrote: > Georg Baum wrote: > > > Uwe Stöhr wrote: > > > >> Am 18.11.2015 um 20:35 schrieb Georg Baum: > > > > Where is the review of the second commit 0ae337014ec6c? I might not have > > looked well enough, but I only saw the one on trac, whic

Re: [patch] support for 'solution' in theorems

Georg Baum wrote: > Uwe Stöhr wrote: > >> Am 18.11.2015 um 20:35 schrieb Georg Baum: > > Where is the review of the second commit 0ae337014ec6c? I might not have > looked well enough, but I only saw the one on trac, which did only cover > the first commit cc6c86ff3b7. > >>> Changing the AMS the

Re: [LyX/master] theorems-ams: add solution environment

Am 23.11.2015 um 13:18 schrieb Kornel Benko: >> diff --git a/lib/layouts/theorems-ams.inc b/lib/layouts/theorems-ams.inc +Style Solution + CopyStyle Definition + LatexName sol + LabelString "Solution \thetheorem." Uwe, ar

Re: [LyX/master] theorems-ams: add solution environment

gt; > > theorems-ams: add solution environment > > > > fixes bug #6363 now completely > > > ... > > diff --git a/lib/layouts/theorems-ams.inc b/lib/layouts/theorems-ams.inc > > index 85eb2b6..55e9466 100644 > > --- a/lib/layouts

Re: [patch] support for 'solution' in theorems

it cannot > know if e.g. the environment "xca" should be taken from theorems or > theorems AMS. Thanks, now I understand, aned I can reproduce that behaviour. This is a bug (which is most likely independent of the new solution environment, it would occur with any of the previously

Re: [LyX/master] theorems-ams: add solution environment

Am Mittwoch, 18. November 2015 um 02:36:56, schrieb Uwe Stöhr > commit 0ae337014ec6cfbe7bb884c4f70b8e66764c22c8 > Author: Uwe Stöhr > Date: Wed Nov 18 02:36:49 2015 +0100 > > theorems-ams: add solution environment > > fixes bug #6363 now completely >

Re: [patch] support for 'solution' in theorems

should be taken from theorems or theorems AMS. However, it was better to add solution to all theorem modules. There is no reason to not have this in AMS. BTW, you are hopefully aware of the current commit rules (trivial changes may go in directly, anything else needs to be supported by at

Re: [patch] support for 'solution' in theorems

Uwe Stöhr wrote: > OK, tex2lyx forced me to add the solution environment also to the AMS > theorem modules. Now the testfile works. How can tex2lyx force you to touch completely unrelated modules? This looks like a bug in tex2lyx, which should be addressed properly. BTW, you are hop

Re: [patch] support for 'solution' in theorems

ng the > \newtheorem statements from the preamble. But when using the attached > TeX test file, the solution environment is not recognized as such and > ERT is created. So I was asking what I should or maybe even must do. Sorry, your question was "Do I have to add special tex2lyx

Re: [patch] support for 'solution' in theorems

Am 18.11.2015 um 01:43 schrieb Uwe Stöhr: The point is that tex2lyx reads theorems in a generic way by reading the \newtheorem statements from the preamble. But when using the attached TeX test file, the solution environment is not recognized as such and ERT is created. So I was asking what I

Re: [patch] support for 'solution' in theorems

, the solution environment is not recognized as such and ERT is created. So I was asking what I should or maybe even must do. For now, since nobody objected and as Jürgen reviewed it I put it in. I want to adapt tex2lyx anyway. thanks and regards Uwe %% LyX 2.2.0alpha1 created this file. For more

Re: [patch] support for 'solution' in theorems

Uwe Stöhr wrote: > The attached patch would fix the longstanding bug > > http://www.lyx.org/trac/ticket/6363 > > This would be a fileformat change and that is why Scott wanted to have > this in after alpha 1. The actual file format change is missing, I guess this will be in the final version?

Re: [patch] support for 'solution' in theorems

On 11/16/2015 07:13 PM, Uwe Stöhr wrote: > The attached patch would fix the longstanding bug > > > http://www.lyx.org/trac/ticket/6363 > > This would be a fileformat change and that is why Scott wanted to have this in after alpha 1. > > OK to proceed or do I have to add special tex2lyx things? I

[patch] support for 'solution' in theorems

-bytype.inc b/lib/layouts/theorems-bytype.inc index fb8992d..951b3fd 100644 --- a/lib/layouts/theorems-bytype.inc +++ b/lib/layouts/theorems-bytype.inc @@ -16,6 +16,7 @@ # - Example # - Problem # - Exercise +# - Solution # - Remark # - Claim # - Proof @@ -240,6 +241,25 @@ Style Exercise End

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Le 22/06/2012 09:30, Pavel Sanda a écrit : Now with git this is even absurd since you split logical changes from one commit into two and the hash does not point to the actual changes which one is interested in when looking into history. So I propose to drop the whole idea of adding commit hashes

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Uwe Stöhr wrote: > I don't know why we store the hash/commit number in FORMAT, but there must > be a reason why this was once decided to do so. Maybe JMarc knows this. There was never discussion about this IIRC. Looking back in commit history, its just that Edwin once used it and others followed

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Am 22.06.2012 09:30, schrieb Pavel Sanda: I have committed this in a second commit because I first need to know the commit hash code for the FORMATS file. I have always wondered why you need the commit numbers/hashes in this file. svn/git blame will tell you this in few seconds. I don't know

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Uwe Stöhr wrote: > Am 22.06.2012 01:15, schrieb Pavel Sanda: > >> format file entry missing. > > I have committed this in a second commit because I first need to know the > commit hash code for the FORMATS file. I have always wondered why you need the commit numbers/hashes in this file. svn/git b

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Am 22.06.2012 01:15, schrieb Pavel Sanda: format file entry missing. I have committed this in a second commit because I first need to know the commit hash code for the FORMATS file. regards Uwe

Re: [LyX master] drop support for ArmTeX as its non-standard armscii8 encoding was quite unusable in real life, use polyglossia/XeTeX instead as clean solution via Unicode; fileformat change; fixes th

Uwe StĂśhr wrote: > commit 1ea2abc77f79c1edd20dd01512920417e61074ae > Author: Uwe StĂśhr > Date: Fri Jun 22 01:12:43 2012 +0200 > > drop support for ArmTeX as its non-standard armscii8 encoding was quite > unusable in real life, use polyglossia/XeTeX instead as

Re: solution to www.lyx.org website being down?

On 05/04/2012 06:40 PM, Jeremy Warding wrote: Hi, This is my first time writing to the list. I've noticed that the www.lyx.org and wiki.lyx.org websites are often down. I've done some searching on this list and the developers list and the most common

solution to www.lyx.org website being down?

Hi, This is my first time writing to the list. I've noticed that the www.lyx.organd wiki.lyx.org websites are often down. I've done some searching on this list and the developers list and the most common response to reports of "the website is down" is: "It's back up now". I'm very curious why this

Re: LyX 1.6.10 compilation problem in Fedora 15 - and one solution?

On 09/05/2011 08:26 PM, andre duarte bueno wrote: > Hy > whem I try do compile LyX 1.6.10 > in my fedora 15; X86_64, g++ (GCC) 4.6.0 20110603 (Red Hat 4.6.0-10) Is there any specific reason for not to use lyx 2.0 from the distribution? Regards, -- José Matos

Re: LyX 1.6.10 compilation problem in Fedora 15 - and one solution?

thanks *Prof. André Duarte Bueno, Dr* Engenharia de Software, Análise e Processamento de Imagens *UENF* - Universidade Estadual do Norte Fluminense - Darcy Ribeiro *CCT *- Centro de Ciencias e Tecnologias *LENEP* - Laboratório de Engenharia e Exploração de Petróleo Rodovia Amaral Peixoto, km 163,

Re: LyX 1.6.10 compilation problem in Fedora 15 - and one solution?

andre duarte bueno wrote: > Hy > whem I try do compile LyX 1.6.10 > in my fedora 15; X86_64, g++ (GCC) 4.6.0 20110603 (Red Hat 4.6.0-10) either use lyx 2.0 or get lyx 1.6 from svn where it should be fixed. newer lyx 1.6.11 won't be released. pavel

LyX 1.6.10 compilation problem in Fedora 15 - and one solution?

-1.6.10' make: ** [all] Erro 2 I open file FileNameList and include 2 lines class FileNameList: public std::vector { public: //new FileNameList() : std::vector(){} //new }; after this modification the program compile. please verify thie problem and solution. *Prof. André Duarte

Re: A solution to the problem of Sweave.sty in the sweave module

No. AFAIK, Rtools has nothing to do with Sweave.sty. It is the step 4 in the article you cited that solves this problem: 4. Copy Sweave.sty from share/texmf in the R installation directory to some place in your LaTeX path. Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name De

Re: A solution to the problem of Sweave.sty in the sweave module

On Thu, May 12, 2011 at 5:57 PM, Yihui Xie wrote: > Maybe I have not got what you mean yet -- is the "problem" in your > mind the same as mine? The problem as I can see is about the spaces in > the path to Sweave.sty under Windows, therefore it is more of a LaTeX > problem than an Sweave problem.

Re: A solution to the problem of Sweave.sty in the sweave module

Maybe I have not got what you mean yet -- is the "problem" in your mind the same as mine? The problem as I can see is about the spaces in the path to Sweave.sty under Windows, therefore it is more of a LaTeX problem than an Sweave problem. I know generally it is not a good idea to hard-code anythi

Re: A solution to the problem of Sweave.sty in the sweave module

On Thu, May 12, 2011 at 02:21:02PM +0200, Jean-Marc Lasgouttes wrote: > Le 12/05/2011 03:30, Yihui Xie a écrit : > >Hi all, > > > >I've come up with another idea which has been in my mind for a while. > >Sweave.sty is really short enough to be directly written into the > >LaTeX preamble like this:

Re: A solution to the problem of Sweave.sty in the sweave module

Le 12/05/2011 03:30, Yihui Xie a écrit : Hi all, I've come up with another idea which has been in my mind for a while. Sweave.sty is really short enough to be directly written into the LaTeX preamble like this: %\usepackage{Sweave} \ifdefined\Sinput \else \IfFileExists{Sweave.sty}{ \usepa

Re: A solution to the problem of Sweave.sty in the sweave module

On 2011-05-12, Yihui Xie wrote: >> There is a LaTeX package (http://ctan.org/pkg/grffile) that does this >> for file names. I don't know, whether it would solve your problem, >> though. > I see this package is not included in TeXLive, so it may require the > user to do even more work. Just for t

Re: A solution to the problem of Sweave.sty in the sweave module

do anything for this Sweave package, >> we can of course call >> >> Sweave(..., stylepath = TRUE) > >> >> to ask Sweave to insert the hard-coded path of Sweave.sty in the LaTeX >> output, which is not an ideal solution, since it is known that the >> path to

Re: A solution to the problem of Sweave.sty in the sweave module

Thanks for the hint! I see this package is not included in TeXLive, so it may require the user to do even more work. Even if a user has successfully installed this package and it does work with spaces, the idea of using the 'stylepath' argument with Sweave is bad. The hard-coded path will make the

Re: A solution to the problem of Sweave.sty in the sweave module

E) > >> >> to ask Sweave to insert the hard-coded path of Sweave.sty in the LaTeX >> output, which is not an ideal solution, since it is known that the >> path to Sweave.sty often contains spaces under Windows and LaTeX will >> fail. > > Currently we use sty

Re: A solution to the problem of Sweave.sty in the sweave module

k Sweave to insert the hard-coded path of Sweave.sty in the LaTeX > output, which is not an ideal solution, since it is known that the > path to Sweave.sty often contains spaces under Windows and LaTeX will > fail. Currently we use stylepath automatically. What about having Sweave authors fix t

Re: A solution to the problem of Sweave.sty in the sweave module

I wote for copying file to temporary folder where LyX copies files for LaTeX compilation. Gregor Gorjanc

A solution to the problem of Sweave.sty in the sweave module

under Windows; it is not hard for other operating systems either. 2. if the user does not want to do anything for this Sweave package, we can of course call Sweave(..., stylepath = TRUE) to ask Sweave to insert the hard-coded path of Sweave.sty in the LaTeX output, which is not an ideal sol

Re: lyx 1.6.5/mac - kbd maps + nfs - lyx steals keyboard focus - SOLUTION

It seems that I've found the solution - the "backup original document when saving" option must be switched off. Then it is OK even with NFS mounted home. There must be a bug in the procedure of renaming the orig. file when this is on NFS+being deep into the directory hierarchy

Re: [patch] final solution for configure.py to support eLyXer

On Sunday 08 November 2009 02:00:01 rgheck wrote: > I think Jose has been working on it here and there, but very much behind > the scenes. My own view is that we should do one of these two things, or > both: After some of the current ultra-super-mega busy period is over I will post the code I h

Re: [patch] final solution for configure.py to support eLyXer

review of my patch then. The only person that > commented on the patch offered was Jürgen, who rejected it on purely although i didn't replied to the patch you indeed missed my standpoint for this solution as discussed before :) > > to read another accusations on our heads after just r

Re: [patch] final solution for configure.py to support eLyXer

On 11/09/2009 09:30 AM, Jürgen Spitzmüller wrote: Alex Fernandez wrote: I did miss your review of my patch then. The only person that commented on the patch offered was Jürgen, who rejected it on purely aesthetic grounds: "I do not like the menus to be cluttered". If it is a matter of taste

Re: [patch] final solution for configure.py to support eLyXer

On Mon, Nov 9, 2009 at 2:41 PM, rgheck wrote: > Well, as usual, my own response to these silly comments is to commit code > rather than to have a pointless debate about the same issue all over again. Yeah, you have never been known for trolling incessantly in public, or (lately) to smear other pe

Re: [patch] final solution for configure.py to support eLyXer

Alex Fernandez wrote: > I did miss your review of my patch then. The only person that > commented on the patch offered was Jürgen, who rejected it on purely > aesthetic grounds: "I do not like the menus to be cluttered". If it is > a matter of taste then I don't see why it can't be discussed furthe

Re: [patch] final solution for configure.py to support eLyXer

On Mon, Nov 9, 2009 at 12:55 PM, Pavel Sanda wrote: > if you are really mind-opened to other world views, my proposal is that it has > something to do with the design quality of the patches, than with this list > itself :) I did miss your review of my patch then. The only person that commented o

Re: [patch] final solution for configure.py to support eLyXer

On 11/09/2009 06:55 AM, Pavel Sanda wrote: to read another accusations on our heads after just renouncing work on the convertors patch from Juergen is somewhat absurd. Well, as usual, my own response to these silly comments is to commit code rather than to have a pointless debate about the

Re: [patch] final solution for configure.py to support eLyXer

Alex Fernandez wrote: > On Sun, Nov 8, 2009 at 10:06 PM, rgheck wrote: > >> What is for sure, however, is that warming up this discussion again and > >> again will not help getting it ready either. > > > > Complaints do not do much good, no. > > On the contrary, they are the only way to improveme

Re: [patch] final solution for configure.py to support eLyXer

On 2009-11-06, rgheck wrote: > On 11/06/2009 05:10 AM, Guenter Milde wrote: >> On 2009-11-06, rgheck wrote: ... >> * People that do not like elyxer are advised not to install (or to >>remove/disable it). For the above reasons this is much easier than >>removing htlatex. > How about just

Re: [patch] final solution for configure.py to support eLyXer

On Sun, Nov 8, 2009 at 10:06 PM, rgheck wrote: >> What is for sure, however, is that warming up this discussion again and >> again will not help getting it ready either. > > Complaints do not do much good, no. On the contrary, they are the only way to improvement. But they need people with open e

Re: [patch] final solution for configure.py to support eLyXer

On 11/08/2009 04:07 AM, Jürgen Spitzmüller wrote: Alex Fernandez wrote: Richard was talking about 1.7, but unfortunately we cannot be sure that it will be ready for the 1.7 timeframe either. You're right, we cannot be sure it will be ready. I doubt we can be sure of anything oth

Re: [patch] final solution for configure.py to support eLyXer

Uwe Stöhr wrote: > Sorry for my mistake here. You are right this should go in for branch. > Jürgen? OK. Jürgen

Re: [patch] final solution for configure.py to support eLyXer

On Sun, Nov 8, 2009 at 6:20 PM, Jürgen Spitzmüller wrote: > Alex Fernandez wrote: >> What I don't understand (and I am sure I am not alone in this) is why >> not go for the easy solution now, just for branch. This would solve >> the problem for 1.6.x while leaving t

Re: [patch] final solution for configure.py to support eLyXer

Alex Fernandez schrieb: By the way, when I submitted the patch it worked against trunk, but not against branch -- since trunk uses log() and branch is still using print "". So a version which worked against both necessarily had to remove the log messages. The attached patch restores the log mess

Re: [patch] final solution for configure.py to support eLyXer

Alex Fernandez wrote: > What I don't understand (and I am sure I am not alone in this) is why > not go for the easy solution now, just for branch. This would solve > the problem for 1.6.x while leaving the field open for the good > long-term solution for 1.7. Attached is a patc

Re: [patch] final solution for configure.py to support eLyXer

ethods, and it > essentially depends on my free time and energy. What is for sure, however, is > that warming up this discussion again and again will not help getting it ready > either ;-) What I don't understand (and I am sure I am not alone in this) is why not go for the easy solution now,

Re: [patch] final solution for configure.py to support eLyXer

On Fri, Nov 6, 2009 at 8:49 PM, Uwe Stöhr wrote: > I only want to have the patch in to make configure.py again work on all > platforms. Please discuss all other issues on the list so that everybody can > participate, no matter if this produces more "heat".  My understanding of > democracy is that

  1   2   3   4   >