Re: Embedding Python
I've tried to look into embedding python into lyx, it seems possible as the interpreter was designed for embedding though I haven't yet figured out how to do it exactly. Ok, before we seriously start this kind of implementation I would really like to have this Which scripting languange? argument again. Maybe the proponents of Python would like to collect a list of advantages of this particular languange, the Tcl people do likewise for Tcl and maybe there are a few Perl or VisualBasic people out there too... And please don't argue like XXX can be easily embedded, but I don't really know how. Maybe we could have a small that of tasks that are likely to be solved with scripting langauage and compare how easy it is to solve them with the different languages. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
* Andre Poenitz [EMAIL PROTECTED] [010502 09:36]: I've tried to look into embedding python into lyx, it seems possible as the interpreter was designed for embedding though I haven't yet figured out how to do it exactly. Ok, before we seriously start this kind of implementation I would really like to have this Which scripting languange? argument again. Ok, before we serious start this kind of discussion on Which scripting language? why don't we agree that the best thing is for scripting language to be optional and let the user choose? After all, we do it with GUI, we decided not to decide on anything and to let the users use what fits them better. The same could be with scripting language, after all the hooks for scripting language is another LFUN and another calling name e.g. lisp-script. The implementation is even simpler than GUI and will avoid such a lengthy discussion on the merits of each language. After all, those who are supposed to program those scripts are users, we might need to write some of the scripts, but the scripts are not an important part of LyX, just an add-on. The basics of embedding a language is to have a way to call scripts of this language: ExecutePythonScript(string const filename) And then we need to expose the lyx actions and queries to the scripting language, this entails an extension to LyXFunc that can also query. We need actions like word-forward (which we have now) and queries like character-get (which we dont have). So the exposing part is equal for all languages, and the wrappings of these for the specific language are specific to the language. Notice that in my patch I started a new subdirectory src/embed/ for this exact reason. My reason to use Python is because it's a language I like. I do not really like lisp or scheme or their other variants. It's pretty hard to argue on the basis of I like this language or that language, and I believe most of us have language that we prefer to script in. It will be hard to quantify the betterness (for lack of the correct word) of a language to implement some script. -- Baruch Even http://baruch.ev-en.org/
Re: Embedding Python
There's an archive of most of the previous discussions at: http://www.mail-archive.com/lyx-devel@lists.lyx.org/ Do you really want repeat all that again? For a fourth time? Allan. (ARRae)
Re: Thank you!
Amir == Amir Karger [EMAIL PROTECTED] writes: Amir Sorry for my lack of clarity. v1.0 is me or my wife. It's not my Amir joke; it's recycled from JMarc, so accuse him if it didn't make Amir sense. It's probably that I read too much about Linus v2.0 at the time. So it is some kind of overrecycling syndrome (if this makes sense). All in all, I missed the big congratulation session last week. Since all the funny and/or nice things have already been written, I'll just add « félicitations ! », which obviously means the same, but has not been taken by others yet. JMarc
Re: 1.1.6fix2???
Ulrich == Ulrich Günther [EMAIL PROTECTED] writes: Ulrich 1.1.6fix1 has a number of nasty bugs in tables (highlighting, Ulrich maneuvering is broken, it is not possible any more to apply Ulrich formatting to the entire table ...). Ulrich Is there still a change to get a 1.1.6fix2? I'd like to get fix2 out this week, but I have to warn you that it does not solve most of the table problems... These need more major surgery and are 1.2.0-only changes. JMarc
Re: Embedding Python
Maybe we could have a small that of tasks that are likely to be solved with scripting langauage and compare how easy it is to solve them with the different languages. To be read as: Maybe we could have a compiliation of a small set of tasks that are likely to be solved with scripting languages within LyX and compare how easy it is to solve them with the different languages. Andre', waiting for his tea... -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
Ok, before we serious start this kind of discussion on Which scripting language? why don't we agree that the best thing is for scripting language to be optional and let the user choose? Good point. If you leave out Python off the core, I won't argue. On the other hands there are a few tasks _within_ LyX that easily can be solved with scripting (like parsing certain configuration files or adding improved functionality for configuration files like if/then/else), so having _one_ language closer to the core might be sensible. But I think that would be post 1.2 matter anyway... The basics of embedding a language is to have a way to call scripts of this language: ExecutePythonScript(string const filename) And then we need to expose the lyx actions and queries to the scripting language, this entails an extension to LyXFunc that can also query. We need actions like word-forward (which we have now) and queries like character-get (which we dont have). Right to the mark. We need some low level lyxfunctions in some consistent, simple-to-understand, well-documented style. Maybe that's the point where the effort should be spend... It will be hard to quantify the betterness (for lack of the correct word) of a language to implement some script. Not really. Take proponents of each choice and have a shoot out, i.e. pose a (small) set of problems and have them solved by the proponents. Look at the result. If one needs 100 lines and the second only five, and the code of the second looks readable even to people who don't know that language, the second is better. It works rather well if you really have people familiar with the languages. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: 1.1.6fix2???
I'd like to get fix2 out this week, but I have to warn you that it does not solve most of the table problems... These need more major surgery and are 1.2.0-only changes. So what is the officially recommended Last Stable Version now? I keep recommending 1.1.5fixsomething or even 1.1.4fixsomething, but I do not really know what I am talking about. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: 1.1.6fix2???
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre So what is the officially recommended Last Stable Version Andre now? Andre I keep recommending 1.1.5fixsomething or even Andre 1.1.4fixsomething, but I do not really know what I am talking Andre about. I'd say that 1.1.6fix? is fine for people who do not use a lot of tables. But I do not really know what I am talking about either. JMarc
Re: Embedding Python
* Andre Poenitz [EMAIL PROTECTED] [010502 10:28]: Ok, before we serious start this kind of discussion on Which scripting language? why don't we agree that the best thing is for scripting language to be optional and let the user choose? Good point. If you leave out Python off the core, I won't argue. On the other hands there are a few tasks _within_ LyX that easily can be solved with scripting (like parsing certain configuration files or adding improved functionality for configuration files like if/then/else), so having _one_ language closer to the core might be sensible. I went to read the past discussion and changed my mind. It can and possibly is important to choose a language, in order to be able to provide scripts to do various tasks outside the LyX core. I do not have a concrete idea, I thought about uppercase character, but this depends on locale and is probably best done in LyX with its future unicode support (though Python has unicode strings ;-) Currently every little function to be done is added to the LyX core (as in the C++ code), having a blessed scripting language will allow us to add functions without cluttering the core with things that are not strictly necessary. This can avoid the MS Office bloat where every small demand of some large customer is inflicted on the whole world. But I think that would be post 1.2 matter anyway... Yes, but it doesn't mean we can't continue to fill the mailboxes of everyone and the mailing list archive :-) The basics of embedding a language is to have a way to call scripts of this language: ExecutePythonScript(string const filename) And then we need to expose the lyx actions and queries to the scripting language, this entails an extension to LyXFunc that can also query. We need actions like word-forward (which we have now) and queries like character-get (which we dont have). Right to the mark. We need some low level lyxfunctions in some consistent, simple-to-understand, well-documented style. Maybe that's the point where the effort should be spend... For the Python embedding the only thing left now is to have these actions available for the script. I have implemented the embedding, the automatic configuration (stolen from glimmer) and added a manual override for those who don't want the embedding even if they have python installed. The rest is empowering the scripts to do something usefull. (Actually, I still need to implement the running of a script file, currently you can run a script in a string... the difference is small and the task is trivial). It will be hard to quantify the betterness (for lack of the correct word) of a language to implement some script. Not really. Take proponents of each choice and have a shoot out, i.e. pose a (small) set of problems and have them solved by the proponents. Look at the result. If one needs 100 lines and the second only five, and the code of the second looks readable even to people who don't know that language, the second is better. It works rather well if you really have people familiar with the languages. Hmmm, ok. But one thing that raised in the former discussion is the fact that we need to target the language at novices and those who are not programmers, the example given there is Amirs Mom, I'm pretty sure she groks Perl scripts, but most peoples probably don't know how to program and so the language need to be a clear one and easy to learn for non-programmers. -- Baruch Even http://baruch.ev-en.org/
Small mathed compilation fixes commited
I just commited the attached patch to cvs. It only matters when using lyxstring. It is afaik harmless, but since mathed is such a sensitive beast, I thought I'd just post it there too. JMarc Index: src/mathed/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v retrieving revision 1.79 diff -u -r1.79 ChangeLog --- src/mathed/ChangeLog2001/04/27 12:35:55 1.79 +++ src/mathed/ChangeLog2001/05/02 08:17:39 @@ -1,3 +1,14 @@ +2001-05-02 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * math_macrotemplate.h: do not use explicitely std::string, but + string. + + * math_macroarg.C: avoid bringing the whole std:: namespace in + global-land. When you do that, there is an ambiguity between + lyxstring and std::string (which may be defined at the same time). + + * formula.C (HandleExtern): add .c_str() to .str() (useful when + using lyxtring) 2001-04-27 André Pönitz [EMAIL PROTECTED] Index: src/mathed/formula.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formula.C,v retrieving revision 1.102 diff -u -r1.102 formula.C --- src/mathed/formula.C2001/04/27 20:26:24 1.102 +++ src/mathed/formula.C2001/05/02 08:17:39 @@ -1419,7 +1419,7 @@ string outfile = /tmp/lyx2 + arg + .out; ostringstream os; par-WriteNormal(os); - string code = os.str(); + string code = os.str().c_str(); string script = lyx2 + arg + ' + code + ' + outfile; lyxerr calling: script endl; Systemcalls cmd(Systemcalls::System, script, 0); Index: src/mathed/math_macroarg.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macroarg.C,v retrieving revision 1.8 diff -u -r1.8 math_macroarg.C --- src/mathed/math_macroarg.C 2001/04/27 12:35:55 1.8 +++ src/mathed/math_macroarg.C 2001/05/02 08:17:39 @@ -10,8 +10,7 @@ #include Lsstream.h #include debug.h - -using namespace std; +using std::endl; MathMacroArgument::MathMacroArgument(int n) : MathedInset(string(), LM_OT_MACRO_ARG, LM_ST_TEXT), Index: src/mathed/math_macrotemplate.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.C,v retrieving revision 1.16 diff -u -r1.16 math_macrotemplate.C --- src/mathed/math_macrotemplate.C 2001/04/25 15:43:57 1.16 +++ src/mathed/math_macrotemplate.C 2001/05/02 08:17:39 @@ -12,7 +12,7 @@ #include debug.h #include Painter.h -using namespace std; +//using namespace std; MathMacroTemplate::MathMacroTemplate() : MathParInset(LM_ST_TEXT, undefined, LM_OT_MACRO), Index: src/mathed/math_macrotemplate.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.h,v retrieving revision 1.12 diff -u -r1.12 math_macrotemplate.h --- src/mathed/math_macrotemplate.h 2001/04/24 16:13:38 1.12 +++ src/mathed/math_macrotemplate.h 2001/05/02 08:17:39 @@ -22,7 +22,7 @@ /// MathMacroTemplate(); /// - MathMacroTemplate(std::string const name, int nargs); + MathMacroTemplate(string const name, int nargs); /// void WriteDef(std::ostream , bool fragile) const; /// Number of arguments
Re: Problem compiling lyx1.1.6fix1 on rh7.0 alpha (bis)
Yann == Yann MORERE [EMAIL PROTECTED] writes: Yann Hello the dream team... I've got problem compiling the 1.1.6fix1 Yann release of lyx Replace your xforms package with the one found in ftp.sylvan.com/pub/lyx. This is a better one. For the warning with _, I don't know what this means. Do you have the latest gcc updates for RH7? JMarc
Re: SUN CC 6.0 Update 1 compiles !!! (almost)
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael you never stop learning new options. Enclosed please find the Michael output of cvs diff -u. Note that with a .cvsrc like cvs -z6 diff -u rdiff -u update -dP you will get the right options automatically, and a few other things. I commited the part concerning using, since I am not sure about whether the rest is the right way. I'll let Allan comment on this. JMarc
Re: Embedding Python
It works rather well if you really have people familiar with the languages. Hmmm, ok. But one thing that raised in the former discussion is the fact that we need to target the language at novices and those who are not programmers, the example given there is Amirs Mom, I'm pretty sure she groks Perl scripts, but most peoples probably don't know how to program and so the language need to be a clear one and easy to learn for non-programmers. I mean for the shoot out you need people familiar with the language to get a fairly unbiased result. Algorithms/functions working well in one language do not necessarily work well in another (heck, I have had people claiming that Java is faster than C++ since one particular implementation of an algorithm that no sensible C++-programmer would code that way was faster in Java...) I agree that actual usage of the language has to be as easy as possible. And it would be nice if the LyX core could benefit from the language's capabilities - i.e. we don't actually need our own unicode handling if the script language provided a reasonable interface to its own unicode handling. The same holds true for platform independent file handling or spawning of external processes for which we currently only have some scetchy native LyX support (and which would really become a mess once you'd like to extend that to non-Unixoid systems...) It looks like nobody really argues the necessity of _some_ embedded scripting language, and it does not look like somebody wants to roll our own. I think we agree on the necessity of low-level LyXFunctions, which are good per se since they could help to break the more complex ones into smaller, easier maintainable parts. So if somebody would start working there ;-} Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On Wed, 2 May 2001, Andre Poenitz wrote: It works rather well if you really have people familiar with the languages. Hmmm, ok. But one thing that raised in the former discussion is the fact that we need to target the language at novices and those who are not programmers, the example given there is Amirs Mom, I'm pretty sure she groks Perl scripts, but most peoples probably don't know how to program and so the language need to be a clear one and easy to learn for non-programmers. I mean for the shoot out you need people familiar with the language to get a fairly unbiased result. Algorithms/functions working well in one language do not necessarily work well in another (heck, I have had people claiming that Java is faster than C++ since one particular implementation of an algorithm that no sensible C++-programmer would code that way was faster in Java...) I agree with that. It looks like nobody really argues the necessity of _some_ embedded scripting language, and it does not look like somebody wants to roll our own. Rolling our own is not such a good idea, unless one of the developers is a language developer on his spare time (or work time). Language design for a language that would be easy to use and useful is not a simple task. I think we agree on the necessity of low-level LyXFunctions, which are good per se since they could help to break the more complex ones into smaller, easier maintainable parts. So if somebody would start working there ;-} I think Lars is already bored with saying that he doesn't want any such code in LyX proper right now, so this whole embedding stuff is to be delayed, it will be pretty hard to maintain such a thing without having it in CVS. Lars, will you make a concession to accept the embedding code into a branch? It might be better anyhow to work this out in a branch rather than on the trunk. Baruch
Re: Small mathed compilation fixes commited
I just commited the attached patch to cvs. It only matters when using lyxstring. It is afaik harmless, but since mathed is such a sensitive beast, I thought I'd just post it there too. Nice move ;-) Andre' PS: I am still sloppier than I'd like to be with std:: *sigh* -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
I think Lars is already bored with saying that he doesn't want any such code in LyX proper right now, I do hope he is ;-) so this whole embedding stuff is to be delayed, it will be pretty hard to maintain such a thing without having it in CVS. Lars, will you make a concession to accept the embedding code into a branch? It might be better anyhow to work this out in a branch rather than on the trunk. Once started it should not affect trunk code much. So it should not be too hard to do it on the main trunk once everything else is done *cough*, 1.2 is out, and so on. Starting a branch right now would probably mean making the language decision _now_ and that is something I oppose. Preliminary necessary stuff like finding some naming scheme for the required low level LyXFunc stuff do not need a branch either, and I'd doubt that the corresponding implementation is worth the branching either. So my prefered road map would be to get current CVS stable (mathed is certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the asbestos suits, and than start with language specific work... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On Wed, 2 May 2001, Andre Poenitz wrote: so this whole embedding stuff is to be delayed, it will be pretty hard to maintain such a thing without having it in CVS. Lars, will you make a concession to accept the embedding code into a branch? It might be better anyhow to work this out in a branch rather than on the trunk. Once started it should not affect trunk code much. So it should not be too hard to do it on the main trunk once everything else is done *cough*, 1.2 is out, and so on. Doing various things like character-delete will probably touch some trunk code. but what do I know, I havent played with the core so far. Starting a branch right now would probably mean making the language decision _now_ and that is something I oppose. Not necessarily, we agreed(?) that the core now is the lyxfunc-alike support methods, and the Official embedded language should be named before release (and be complete for the release). Theoretically after everything is in place, adding a language shouldn't be more than a day or two of work. The hard part is finding how to do the configure script and how to link everything to LyX, once this is solved the rest is simple. Preliminary necessary stuff like finding some naming scheme for the required low level LyXFunc stuff do not need a branch either, and I'd doubt that the corresponding implementation is worth the branching either. So my prefered road map would be to get current CVS stable (mathed is certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the asbestos suits, and than start with language specific work... I'm no CVS guru, it's your call on what to do and what not to do on a branch. Though my idea is that we work the implementation on a branch and when everything in it is stable enough we merge it back. This is probably what should have been done with table and mathed, but then Lars is the overlord and what he says goes. I have no problem delaying everything until 1.2.0, I should probably return to InsetGraphics to complete it or at least make it presentable in 1.2.0 Baruch
Re: Embedding Python
Andre Poenitz [EMAIL PROTECTED] writes: | I think Lars is already bored with saying that he doesn't want any such | code in LyX proper right now, | | I do hope he is ;-) | so this whole embedding stuff is to be delayed, it will be pretty hard | to maintain such a thing without having it in CVS. | | Lars, will you make a concession to accept the embedding code into a | branch? It might be better anyhow to work this out in a branch rather | than on the trunk. | | Once started it should not affect trunk code much. So it should not be | too hard to do it on the main trunk once everything else is done *cough*, | 1.2 is out, and so on. | | Starting a branch right now would probably mean making the language | decision _now_ and that is something I oppose. agree | Preliminary necessary stuff like finding some naming scheme for the | required low level LyXFunc stuff do not need a branch either, and I'd | doubt that the corresponding implementation is worth the branching either. | | So my prefered road map would be to get current CVS stable (mathed is | certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the | asbestos suits, and than start with language specific work... To get the GUII work _done_ should be higher priority than an embedded language. -- Lgb
Re: Embedding Python
Baruch Even [EMAIL PROTECTED] writes: | I have no problem delaying everything until 1.2.0, I should probably | return to InsetGraphics to complete it or at least make it presentable in | 1.2.0 Yes, please. -- Lgb
Re: double spaces at the end of a sentence: readability
Moving this comment over here (if it hasn't already been moved here) since it has been suggested this is a more appropriate location: On Tuesday 01 May 2001 14:44, Laura Jackson wrote: Why couldn't LyX allow the user to type 2 spaces between sentences and 1 space between words? It's frustrating to read over the text written in LyX and have the sentences all squashed together. Personally, I don't have a problem with the single spaces at ends of sentences. However, as a person who learned to type on a typewriter, my fingers have been trained by over 20 years of typing to hit the spacebar twice at the end of a sentence. What does form at least a minor irritant is the message about not being about to insert two spaces. I just wish there was a way to turn this one message off. It really does tend to break one's concentration when trying to type a document. -- George J. De Bruin Check Out 0l0rin's New Age compositions at http://mp3.com/0l0rin 0l0rin's latest recording Collection is available now!
Position of the Lsstream.h header?
In most of the C++ files incuding Lsstream.h, this file is just after config.h, and even before LString.h and the implementation pragmas. This makes LString.h output an error with gcc 2.95.3+lyxstring. Is it OK if I move it later in the include list or is there some subtle reason I am missing? JMarc
latest cvs - math-label
running latex on my doc with amsmath-option gave a lot of errors, thats amsmath detected always dublicated labels in equations. don't really know, what's going on there i tested math-labeling. it's possible to insert a label for the blue math box, but it's never saved and displayed, always the #-symbol. Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: latest cvs - math-label
running latex on my doc with amsmath-option gave a lot of errors, thats amsmath detected always dublicated labels in equations. don't really know, what's going on there i tested math-labeling. Labels and numbers are currently completely broken. I am right now rewriting the multiline stuff, so it hopefully will be fixed within the next few days. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On 2 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: Baruch Even [EMAIL PROTECTED] writes: | I have no problem delaying everything until 1.2.0, I should probably | return to InsetGraphics to complete it or at least make it presentable in | 1.2.0 Yes, please. yeah, being able to kill the old figure stuff would be really nice ! ;) john -- Given standard traffic patterns, Linus Torvalds has an 8.9% (plus or minus 1.4%) chance of surviving and fully recovering from a collision with a bus. - Segfault
Re: Position of the Lsstream.h header?
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | In most of the C++ files incuding Lsstream.h, this file is just after | config.h, and even before LString.h and the implementation pragmas. | This makes LString.h output an error with gcc 2.95.3+lyxstring. Is it | OK if I move it later in the include list or is there some subtle | reason I am missing? No, I don't think so. Just move it. -- Lgb
InsetGraphics
* John Levon [EMAIL PROTECTED] [010502 22:37]: On 2 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: Baruch Even [EMAIL PROTECTED] writes: | I have no problem delaying everything until 1.2.0, I should probably | return to InsetGraphics to complete it or at least make it presentable in | 1.2.0 Yes, please. yeah, being able to kill the old figure stuff would be really nice ! ;) I know that, but I'm still out of ideas on how to implement the background conversion, the image resize and image dithering. I'll probably need to define something similar to Converter but geared specifically for images and with the above three requirements. I can see no other solution. -- Baruch Even http://baruch.ev-en.org/
Buglet: Double-quotes in footnotes
In the latest CVS, Double quotes in footnotes are inserted as '' (instead of `` followed by '' when you close the quote). Copying/pasting the correct quote from another part of the document works as a workaround. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Buglet: Double-quotes in footnotes
On Wed, May 02, 2001 at 04:50:21PM -0700, Kayvan A. Sylvan wrote:
In the latest CVS,
Double quotes in footnotes are inserted as '' (instead of `` followed
by '' when you close the quote).
Copying/pasting the correct quote from another part of the document
works as a workaround.
This is not a general problem. It only happens in some files.
I've enclosed a lyx file that shows this weird behavior.
Put the cursor before the ``Cursor Here'' and type a double quote and the
right double quote shows up. Put in after the ``C'' (or almost anywhere else
in the document) and type a double-quote and the wrong quote is inserted.
Hopefully this bug report is more useful.
---Kayvan
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass literate-article
\begin_preamble
%
% This is for good PDF production (with hyperlinks)
%
\usepackage[ps2pdf,pdftitle={MSite Multisite
Suite},urlcolor=blue,linktocpage,letterpaper,colorlinks=true]{hyperref}
\newcommand{\tocchap}[1]{\addcontentsline{toc}{section}{\protect\numberline{}#1}}
\newcommand{\tocsect}[1]{\addcontentsline{toc}{subsection}{\protect\numberline{}#1}}
%
% This (from the noweb FAQ) relaxes the constraint that chunks are never broken across
pages.
%
\def\nwendcode{\endtrivlist \endgroup \vfil\penalty10\vfilneg}
\let\nwdocspar=\smallbreak
%
% This is from Herbert Voss LyX tips web pages
%
\usepackage{pstcol}% PSTricks with the `color' extension
\usepackage[tiling]{pst-fill} % PSTricks package for filling/tiling
\usepackage{pst-node} % PSTricks package for nodes
\usepackage{pst-char} % PSTricks package for character path
\usepackage{pst-grad} % PSTricks package for gradient filling
\usepackage{multido} % `multido' package
\usepackage{graphicx} % `graphicx' package
\usepackage{pstricks}
\newcommand{\WriteBig}[3] {
\DeclareFixedFont{\bigsf}{T1}{phv}{b}{n}{#2}
\DeclareFixedFont{\smallrm}{T1}{ptm}{m}{n}{#3}
\psboxfill{\smallrm #1}
\begin{center}
\begin{pspicture*}(\columnwidth,4)
\centerline{\pscharpath[fillstyle=gradient,gradangle=-45,gradmidpoint=0.5,addfillstyle=boxfill,fillangle=45,fillsep=0.7mm]{\rput[b](0,0){\bigsf#1}}}
\end{pspicture*}
\end{center}
}
\end_preamble
\language english
\inputencoding latin1
\fontscheme pslatex
\graphics default
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout LaTeX
\layout Standard
\align center
\size huge
Cursor Here
\layout Standard
\added_space_top medskip \added_space_bottom medskip \align center
\size larger
Kayvan A.
Sylvan
\layout Standard
\align center
\size large
5/2/2001
\the_end
Re: Embedding Python
> I've tried to look into embedding python into lyx, it seems possible as > the interpreter was designed for embedding though I haven't yet figured > out how to do it exactly. Ok, before we seriously start this kind of implementation I would really like to have this "Which scripting languange?" argument again. Maybe the proponents of Python would like to collect a list of advantages of this particular languange, the "Tcl people" do likewise for Tcl and maybe there are a few Perl or VisualBasic people out there too... And please don't argue like "XXX can be easily embedded, but I don't really know how". Maybe we could have a small that of tasks that are likely to be solved with scripting langauage and compare how easy it is to solve them with the different languages. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
* Andre Poenitz <[EMAIL PROTECTED]> [010502 09:36]: > > I've tried to look into embedding python into lyx, it seems possible as > > the interpreter was designed for embedding though I haven't yet figured > > out how to do it exactly. > > Ok, before we seriously start this kind of implementation I would really > like to have this "Which scripting languange?" argument again. Ok, before we serious start this kind of discussion on "Which scripting language?" why don't we agree that the best thing is for scripting language to be optional and let the user choose? After all, we do it with GUI, we decided not to decide on anything and to let the users use what fits them better. The same could be with scripting language, after all the hooks for scripting language is another LFUN and another calling name e.g. lisp-script. The implementation is even simpler than GUI and will avoid such a lengthy discussion on the merits of each language. After all, those who are supposed to program those scripts are users, we might need to write some of the scripts, but the scripts are not an important part of LyX, just an add-on. The basics of embedding a language is to have a way to call scripts of this language: ExecutePythonScript(string const & filename) And then we need to expose the lyx actions and queries to the scripting language, this entails an extension to LyXFunc that can also query. We need actions like "word-forward" (which we have now) and queries like "character-get" (which we dont have). So the exposing part is equal for all languages, and the wrappings of these for the specific language are specific to the language. Notice that in my patch I started a new subdirectory src/embed/ for this exact reason. My reason to use Python is because it's a language I like. I do not really like lisp or scheme or their other variants. It's pretty hard to argue on the basis of I like this language or that language, and I believe most of us have language that we prefer to script in. It will be hard to quantify the "betterness" (for lack of the correct word) of a language to implement some script. -- Baruch Even http://baruch.ev-en.org/
Re: Embedding Python
There's an archive of most of the previous discussions at: http://www.mail-archive.com/lyx-devel@lists.lyx.org/ Do you really want repeat all that again? For a fourth time? Allan. (ARRae)
Re: Thank you!
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> Sorry for my lack of clarity. v1.0 is me or my wife. It's not my Amir> joke; it's recycled from JMarc, so accuse him if it didn't make Amir> sense. It's probably that I read too much about Linus v2.0 at the time. So it is some kind of overrecycling syndrome (if this makes sense). All in all, I missed the big congratulation session last week. Since all the funny and/or nice things have already been written, I'll just add « félicitations ! », which obviously means the same, but has not been taken by others yet. JMarc
Re: 1.1.6fix2???
> "Ulrich" == Ulrich Günther <[EMAIL PROTECTED]> writes: Ulrich> 1.1.6fix1 has a number of nasty bugs in tables (highlighting, Ulrich> maneuvering is broken, it is not possible any more to apply Ulrich> formatting to the entire table ...). Ulrich> Is there still a change to get a 1.1.6fix2? I'd like to get fix2 out this week, but I have to warn you that it does not solve most of the table problems... These need more major surgery and are 1.2.0-only changes. JMarc
Re: Embedding Python
> Maybe we could have a small that of tasks that are likely to be solved with > scripting langauage and compare how easy it is to solve them with the > different languages. To be read as: > Maybe we could have a compiliation of a small set of tasks that are > likely to be solved with scripting languages within LyX and compare how > easy it is to solve them with the different languages. Andre', waiting for his tea... -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
> Ok, before we serious start this kind of discussion on "Which scripting > language?" why don't we agree that the best thing is for scripting > language to be optional and let the user choose? Good point. If you leave out Python off the core, I won't argue. On the other hands there are a few tasks _within_ LyX that easily can be solved with scripting (like parsing certain configuration files or adding improved functionality for configuration files like if/then/else), so having _one_ language closer to the core might be sensible. But I think that would be post 1.2 matter anyway... > The basics of embedding a language is to have a way to call scripts of > this language: ExecutePythonScript(string const & filename) > And then we need to expose the lyx actions and queries to the scripting > language, this entails an extension to LyXFunc that can also query. We > need actions like "word-forward" (which we have now) and queries like > "character-get" (which we dont have). Right to the mark. We need some "low level lyxfunctions" in some consistent, simple-to-understand, well-documented style. Maybe that's the point where the effort should be spend... > It will be hard to quantify the "betterness" (for lack of the correct > word) of a language to implement some script. Not really. Take proponents of each choice and have a "shoot out", i.e. pose a (small) set of problems and have them solved by the proponents. Look at the result. If one needs 100 lines and the second only five, and the code of the second looks readable even to people who don't know that language, the second is "better". It works rather well if you really have people familiar with the languages. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: 1.1.6fix2???
> I'd like to get fix2 out this week, but I have to warn you that it > does not solve most of the table problems... These need more major > surgery and are 1.2.0-only changes. So what is the officially recommended "Last Stable Version" now? I keep recommending 1.1.5fix or even 1.1.4fix, but I do not really know what I am talking about. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: 1.1.6fix2???
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> So what is the officially recommended "Last Stable Version" Andre> now? Andre> I keep recommending 1.1.5fix or even Andre> 1.1.4fix, but I do not really know what I am talking Andre> about. I'd say that 1.1.6fix? is fine for people who do not use a lot of tables. But I do not really know what I am talking about either. JMarc
Re: Embedding Python
* Andre Poenitz <[EMAIL PROTECTED]> [010502 10:28]: > > Ok, before we serious start this kind of discussion on "Which scripting > > language?" why don't we agree that the best thing is for scripting > > language to be optional and let the user choose? > > Good point. If you leave out Python off the core, I won't argue. > > On the other hands there are a few tasks _within_ LyX that easily can be > solved with scripting (like parsing certain configuration files or adding > improved functionality for configuration files like if/then/else), so > having _one_ language closer to the core might be sensible. I went to read the past discussion and changed my mind. It can and possibly is important to choose a language, in order to be able to provide scripts to do various tasks outside the LyX core. I do not have a concrete idea, I thought about uppercase character, but this depends on locale and is probably best done in LyX with its future unicode support (though Python has unicode strings ;-) Currently every little function to be done is added to the LyX core (as in the C++ code), having a blessed scripting language will allow us to add functions without cluttering the core with things that are not strictly necessary. This can avoid the MS Office bloat where every small demand of some large customer is inflicted on the whole world. > But I think that would be post 1.2 matter anyway... Yes, but it doesn't mean we can't continue to fill the mailboxes of everyone and the mailing list archive :-) > > The basics of embedding a language is to have a way to call scripts of > > this language: ExecutePythonScript(string const & filename) > > And then we need to expose the lyx actions and queries to the scripting > > language, this entails an extension to LyXFunc that can also query. We > > need actions like "word-forward" (which we have now) and queries like > > "character-get" (which we dont have). > > Right to the mark. We need some "low level lyxfunctions" in some > consistent, simple-to-understand, well-documented style. Maybe that's the > point where the effort should be spend... For the Python embedding the "only" thing left now is to have these actions available for the script. I have implemented the embedding, the automatic configuration (stolen from glimmer) and added a manual override for those who don't want the embedding even if they have python installed. The rest is empowering the scripts to do something usefull. (Actually, I still need to implement the running of a script file, currently you can run a script in a string... the difference is small and the task is trivial). > > It will be hard to quantify the "betterness" (for lack of the correct > > word) of a language to implement some script. > > Not really. Take proponents of each choice and have a "shoot out", i.e. > pose a (small) set of problems and have them solved by the proponents. > Look at the result. If one needs 100 lines and the second only five, and > the code of the second looks readable even to people who don't know that > language, the second is "better". > > It works rather well if you really have people familiar with the languages. Hmmm, ok. But one thing that raised in the former discussion is the fact that we need to target the language at novices and those who are not programmers, the example given there is Amirs Mom, I'm pretty sure she groks Perl scripts, but most peoples probably don't know how to program and so the language need to be a clear one and easy to learn for non-programmers. -- Baruch Even http://baruch.ev-en.org/
Small mathed compilation fixes commited
I just commited the attached patch to cvs. It only matters when using lyxstring. It is afaik harmless, but since mathed is such a sensitive beast, I thought I'd just post it there too. JMarc Index: src/mathed/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v retrieving revision 1.79 diff -u -r1.79 ChangeLog --- src/mathed/ChangeLog2001/04/27 12:35:55 1.79 +++ src/mathed/ChangeLog2001/05/02 08:17:39 @@ -1,3 +1,14 @@ +2001-05-02 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * math_macrotemplate.h: do not use explicitely std::string, but + string. + + * math_macroarg.C: avoid bringing the whole std:: namespace in + global-land. When you do that, there is an ambiguity between + lyxstring and std::string (which may be defined at the same time). + + * formula.C (HandleExtern): add .c_str() to .str() (useful when + using lyxtring) 2001-04-27 André Pönitz <[EMAIL PROTECTED]> Index: src/mathed/formula.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formula.C,v retrieving revision 1.102 diff -u -r1.102 formula.C --- src/mathed/formula.C2001/04/27 20:26:24 1.102 +++ src/mathed/formula.C2001/05/02 08:17:39 @@ -1419,7 +1419,7 @@ string outfile = "/tmp/lyx2" + arg + ".out"; ostringstream os; par->WriteNormal(os); - string code = os.str(); + string code = os.str().c_str(); string script = "lyx2" + arg + " '" + code + "' " + outfile; lyxerr << "calling: " << script << endl; Systemcalls cmd(Systemcalls::System, script, 0); Index: src/mathed/math_macroarg.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macroarg.C,v retrieving revision 1.8 diff -u -r1.8 math_macroarg.C --- src/mathed/math_macroarg.C 2001/04/27 12:35:55 1.8 +++ src/mathed/math_macroarg.C 2001/05/02 08:17:39 @@ -10,8 +10,7 @@ #include "Lsstream.h" #include "debug.h" - -using namespace std; +using std::endl; MathMacroArgument::MathMacroArgument(int n) : MathedInset(string(), LM_OT_MACRO_ARG, LM_ST_TEXT), Index: src/mathed/math_macrotemplate.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.C,v retrieving revision 1.16 diff -u -r1.16 math_macrotemplate.C --- src/mathed/math_macrotemplate.C 2001/04/25 15:43:57 1.16 +++ src/mathed/math_macrotemplate.C 2001/05/02 08:17:39 @@ -12,7 +12,7 @@ #include "debug.h" #include "Painter.h" -using namespace std; +//using namespace std; MathMacroTemplate::MathMacroTemplate() : MathParInset(LM_ST_TEXT, "undefined", LM_OT_MACRO), Index: src/mathed/math_macrotemplate.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.h,v retrieving revision 1.12 diff -u -r1.12 math_macrotemplate.h --- src/mathed/math_macrotemplate.h 2001/04/24 16:13:38 1.12 +++ src/mathed/math_macrotemplate.h 2001/05/02 08:17:39 @@ -22,7 +22,7 @@ /// MathMacroTemplate(); /// - MathMacroTemplate(std::string const & name, int nargs); + MathMacroTemplate(string const & name, int nargs); /// void WriteDef(std::ostream &, bool fragile) const; /// Number of arguments
Re: Problem compiling lyx1.1.6fix1 on rh7.0 alpha (bis)
> "Yann" == Yann MORERE <[EMAIL PROTECTED]> writes: Yann> Hello the dream team... I've got problem compiling the 1.1.6fix1 Yann> release of lyx Replace your xforms package with the one found in ftp.sylvan.com/pub/lyx. This is a better one. For the warning with "_", I don't know what this means. Do you have the latest gcc updates for RH7? JMarc
Re: SUN CC 6.0 Update 1 compiles !!! (almost)
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> you never stop learning new options. Enclosed please find the Michael> output of "cvs diff -u". Note that with a .cvsrc like cvs -z6 diff -u rdiff -u update -dP you will get the right options automatically, and a few other things. I commited the part concerning "using", since I am not sure about whether the rest is the "right way". I'll let Allan comment on this. JMarc
Re: Embedding Python
> > It works rather well if you really have people familiar with the languages. > > Hmmm, ok. But one thing that raised in the former discussion is the fact > that we need to target the language at novices and those who are not > programmers, the example given there is Amirs Mom, I'm pretty sure she > groks Perl scripts, but most peoples probably don't know how to program > and so the language need to be a clear one and easy to learn for > non-programmers. I mean for the shoot out you need people familiar with the language to get a fairly unbiased result. Algorithms/functions working well in one language do not necessarily work well in another (heck, I have had people claiming that Java is faster than C++ since one particular implementation of an algorithm that no sensible C++-programmer would code that way was faster in Java...) I agree that actual usage of the language has to be as easy as possible. And it would be nice if the LyX core could benefit from the language's capabilities - i.e. we don't actually need our own unicode handling if the script language provided a reasonable interface to its own unicode handling. The same holds true for platform independent file handling or spawning of external processes for which we currently only have some scetchy "native LyX" support (and which would really become a mess once you'd like to extend that to non-Unixoid systems...) It looks like nobody really argues the necessity of _some_ embedded scripting language, and it does not look like somebody wants to roll our own. I think we agree on the necessity of low-level LyXFunctions, which are good per se since they could help to break the more complex ones into smaller, easier maintainable parts. So if somebody would start working there ;-} Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On Wed, 2 May 2001, Andre Poenitz wrote: > > > It works rather well if you really have people familiar with the languages. > > > > Hmmm, ok. But one thing that raised in the former discussion is the fact > > that we need to target the language at novices and those who are not > > programmers, the example given there is Amirs Mom, I'm pretty sure she > > groks Perl scripts, but most peoples probably don't know how to program > > and so the language need to be a clear one and easy to learn for > > non-programmers. > > I mean for the shoot out you need people familiar with the language to get > a fairly unbiased result. Algorithms/functions working well in one language > do not necessarily work well in another (heck, I have had people claiming > that Java is faster than C++ since one particular implementation of an > algorithm that no sensible C++-programmer would code that way was faster in > Java...) I agree with that. > It looks like nobody really argues the necessity of _some_ embedded > scripting language, and it does not look like somebody wants to roll our > own. Rolling our own is not such a good idea, unless one of the developers is a language developer on his spare time (or work time). Language design for a language that would be easy to use and useful is not a simple task. > I think we agree on the necessity of low-level LyXFunctions, which are good > per se since they could help to break the more complex ones into smaller, > easier maintainable parts. So if somebody would start working there ;-} I think Lars is already bored with saying that he doesn't want any such code in LyX proper right now, so this whole embedding stuff is to be delayed, it will be pretty hard to maintain such a thing without having it in CVS. Lars, will you make a concession to accept the embedding code into a branch? It might be better anyhow to work this out in a branch rather than on the trunk. Baruch
Re: Small mathed compilation fixes commited
> I just commited the attached patch to cvs. It only matters when using > lyxstring. It is afaik harmless, but since mathed is such a sensitive > beast, I thought I'd just post it there too. Nice move ;-) Andre' PS: I am still sloppier than I'd like to be with std:: *sigh* -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
> I think Lars is already bored with saying that he doesn't want any such > code in LyX proper right now, I do hope he is ;-) > so this whole embedding stuff is to be delayed, it will be pretty hard > to maintain such a thing without having it in CVS. > > Lars, will you make a concession to accept the embedding code into a > branch? It might be better anyhow to work this out in a branch rather > than on the trunk. Once started it should not affect "trunk code" much. So it should not be too hard to do it on the main trunk once everything else is done *cough*, 1.2 is out, and so on. Starting a branch right now would probably mean making the language decision _now_ and that is something I oppose. Preliminary necessary stuff like finding some naming scheme for the required low level LyXFunc stuff do not need a branch either, and I'd doubt that the corresponding implementation is worth the branching either. So my prefered road map would be to get current CVS stable (mathed is certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the asbestos suits, and than start with language specific work... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On Wed, 2 May 2001, Andre Poenitz wrote: > > so this whole embedding stuff is to be delayed, it will be pretty hard > > to maintain such a thing without having it in CVS. > > > > Lars, will you make a concession to accept the embedding code into a > > branch? It might be better anyhow to work this out in a branch rather > > than on the trunk. > > Once started it should not affect "trunk code" much. So it should not be > too hard to do it on the main trunk once everything else is done *cough*, > 1.2 is out, and so on. Doing various things like "character-delete" will probably touch some trunk code. but what do I know, I havent played with the core so far. > Starting a branch right now would probably mean making the language > decision _now_ and that is something I oppose. Not necessarily, we agreed(?) that the core now is the lyxfunc-alike support methods, and the "Official embedded language" should be named before release (and be complete for the release). Theoretically after everything is in place, adding a language shouldn't be more than a day or two of work. The hard part is finding how to do the configure script and how to link everything to LyX, once this is solved the rest is simple. > Preliminary necessary stuff like finding some naming scheme for the > required low level LyXFunc stuff do not need a branch either, and I'd > doubt that the corresponding implementation is worth the branching either. > > So my prefered road map would be to get current CVS stable (mathed is > certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the > asbestos suits, and than start with language specific work... I'm no CVS guru, it's your call on what to do and what not to do on a branch. Though my idea is that we work the implementation on a branch and when everything in it is stable enough we merge it back. This is probably what should have been done with table and mathed, but then Lars is the overlord and what he says goes. I have no problem delaying everything until 1.2.0, I should probably return to InsetGraphics to complete it or at least make it presentable in 1.2.0 Baruch
Re: Embedding Python
Andre Poenitz <[EMAIL PROTECTED]> writes: | > I think Lars is already bored with saying that he doesn't want any such | > code in LyX proper right now, | | I do hope he is ;-) | > so this whole embedding stuff is to be delayed, it will be pretty hard | > to maintain such a thing without having it in CVS. | > | > Lars, will you make a concession to accept the embedding code into a | > branch? It might be better anyhow to work this out in a branch rather | > than on the trunk. | | Once started it should not affect "trunk code" much. So it should not be | too hard to do it on the main trunk once everything else is done *cough*, | 1.2 is out, and so on. | | Starting a branch right now would probably mean making the language | decision _now_ and that is something I oppose. agree | Preliminary necessary stuff like finding some naming scheme for the | required low level LyXFunc stuff do not need a branch either, and I'd | doubt that the corresponding implementation is worth the branching either. | | So my prefered road map would be to get current CVS stable (mathed is | certainly not yet ripe for 1.2), get 1.2 out, take a breath, put on the | asbestos suits, and than start with language specific work... To get the GUII work _done_ should be higher priority than an embedded language. -- Lgb
Re: Embedding Python
Baruch Even <[EMAIL PROTECTED]> writes: | I have no problem delaying everything until 1.2.0, I should probably | return to InsetGraphics to complete it or at least make it presentable in | 1.2.0 Yes, please. -- Lgb
Re: double spaces at the end of a sentence: readability
Moving this comment over here (if it hasn't already been moved here) since it has been suggested this is a more appropriate location: On Tuesday 01 May 2001 14:44, Laura Jackson wrote: > Why couldn't LyX allow the user to type 2 spaces between sentences and 1 > space between words? It's frustrating to read over the text written in > LyX and have the sentences all squashed together. Personally, I don't have a problem with the single spaces at ends of sentences. However, as a person who learned to type on a typewriter, my fingers have been trained by over 20 years of typing to hit the spacebar twice at the end of a sentence. What does form at least a minor irritant is the message about not being about to insert two spaces. I just wish there was a way to turn this one message off. It really does tend to break one's concentration when trying to type a document. -- George J. De Bruin Check Out 0l0rin's New Age compositions at http://mp3.com/0l0rin 0l0rin's latest recording "Collection" is available now!
Position of the Lsstream.h header?
In most of the C++ files incuding Lsstream.h, this file is just after config.h, and even before LString.h and the implementation pragmas. This makes LString.h output an error with gcc 2.95.3+lyxstring. Is it OK if I move it later in the include list or is there some subtle reason I am missing? JMarc
latest cvs - math-label
running latex on my doc with amsmath-option gave a lot of errors, thats amsmath detected always dublicated labels in equations. don't really know, what's going on there i tested math-labeling. it's possible to insert a label for the blue math box, but it's never saved and displayed, always the #-symbol. Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: latest cvs - math-label
> running latex on my doc with amsmath-option gave a lot > of errors, thats amsmath detected always dublicated > labels in equations. don't really know, what's going > on there i tested math-labeling. Labels and numbers are currently completely broken. I am right now rewriting the multiline stuff, so it hopefully will be fixed within the next few days. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Embedding Python
On 2 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > Baruch Even <[EMAIL PROTECTED]> writes: > > | I have no problem delaying everything until 1.2.0, I should probably > | return to InsetGraphics to complete it or at least make it presentable in > | 1.2.0 > > Yes, please. yeah, being able to kill the old figure stuff would be really nice ! ;) john -- "Given standard traffic patterns, Linus Torvalds has an 8.9% (plus or minus 1.4%) chance of surviving and fully recovering from a collision with a bus." - Segfault
Re: Position of the Lsstream.h header?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | In most of the C++ files incuding Lsstream.h, this file is just after | config.h, and even before LString.h and the implementation pragmas. | This makes LString.h output an error with gcc 2.95.3+lyxstring. Is it | OK if I move it later in the include list or is there some subtle | reason I am missing? No, I don't think so. Just move it. -- Lgb
InsetGraphics
* John Levon <[EMAIL PROTECTED]> [010502 22:37]: > On 2 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > > > Baruch Even <[EMAIL PROTECTED]> writes: > > > > | I have no problem delaying everything until 1.2.0, I should probably > > | return to InsetGraphics to complete it or at least make it presentable in > > | 1.2.0 > > > > Yes, please. > > yeah, being able to kill the old figure stuff would be really nice ! > > ;) I know that, but I'm still out of ideas on how to implement the background conversion, the image resize and image dithering. I'll probably need to define something similar to Converter but geared specifically for images and with the above three requirements. I can see no other solution. -- Baruch Even http://baruch.ev-en.org/
Buglet: Double-quotes in footnotes
In the latest CVS, Double quotes in footnotes are inserted as '' (instead of `` followed by '' when you close the quote). Copying/pasting the correct quote from another part of the document works as a workaround. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Buglet: Double-quotes in footnotes
On Wed, May 02, 2001 at 04:50:21PM -0700, Kayvan A. Sylvan wrote:
> In the latest CVS,
>
> Double quotes in footnotes are inserted as '' (instead of `` followed
> by '' when you close the quote).
>
> Copying/pasting the correct quote from another part of the document
> works as a workaround.
This is not a general problem. It only happens in some files.
I've enclosed a lyx file that shows this weird behavior.
Put the cursor before the ``Cursor Here'' and type a double quote and the
right double quote shows up. Put in after the ``C'' (or almost anywhere else
in the document) and type a double-quote and the wrong quote is inserted.
Hopefully this bug report is more useful.
---Kayvan
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass literate-article
\begin_preamble
%
% This is for good PDF production (with hyperlinks)
%
\usepackage[ps2pdf,pdftitle={MSite Multisite
Suite},urlcolor=blue,linktocpage,letterpaper,colorlinks=true]{hyperref}
\newcommand{\tocchap}[1]{\addcontentsline{toc}{section}{\protect\numberline{}#1}}
\newcommand{\tocsect}[1]{\addcontentsline{toc}{subsection}{\protect\numberline{}#1}}
%
% This (from the noweb FAQ) relaxes the constraint that chunks are never broken across
pages.
%
\def\nwendcode{\endtrivlist \endgroup \vfil\penalty10\vfilneg}
\let\nwdocspar=\smallbreak
%
% This is from Herbert Voss LyX tips web pages
%
\usepackage{pstcol}% PSTricks with the `color' extension
\usepackage[tiling]{pst-fill} % PSTricks package for filling/tiling
\usepackage{pst-node} % PSTricks package for nodes
\usepackage{pst-char} % PSTricks package for character path
\usepackage{pst-grad} % PSTricks package for gradient filling
\usepackage{multido} % `multido' package
\usepackage{graphicx} % `graphicx' package
\usepackage{pstricks}
\newcommand{\WriteBig}[3] {
\DeclareFixedFont{\bigsf}{T1}{phv}{b}{n}{#2}
\DeclareFixedFont{\smallrm}{T1}{ptm}{m}{n}{#3}
\psboxfill{\smallrm #1}
\begin{center}
\begin{pspicture*}(\columnwidth,4)
\centerline{\pscharpath[fillstyle=gradient,gradangle=-45,gradmidpoint=0.5,addfillstyle=boxfill,fillangle=45,fillsep=0.7mm]{\rput[b](0,0){\bigsf#1}}}
\end{pspicture*}
\end{center}
}
\end_preamble
\language english
\inputencoding latin1
\fontscheme pslatex
\graphics default
\paperfontsize 11
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout LaTeX
\layout Standard
\align center
\size huge
Cursor Here
\layout Standard
\added_space_top medskip \added_space_bottom medskip \align center
\size larger
Kayvan A.
Sylvan
\layout Standard
\align center
\size large
5/2/2001
\the_end
