Re: questions about using Doxygen and Python scripting

On 22/07/2013 4:10 AM, Guenter Milde wrote: On 2013-07-22, Josh Hieronymus wrote: Second, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not worked with Python and C++ in the same project before, so I'm not really sure how to get them to work

Re: questions about using Doxygen and Python scripting

On 22/07/2013 4:10 AM, Guenter Milde wrote: On 2013-07-22, Josh Hieronymus wrote: Second, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not worked with Python and C++ in the same project before, so I'm not really sure how to get them to work

Re: questions about using Doxygen and Python scripting

On 2013-07-22, Josh Hieronymus wrote: ... Second, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not worked with Python and C++ in the same project before, so I'm not really sure how to get them to work together, especially when you consider issues

Re: questions about using Doxygen and Python scripting

On 2013-07-22, Josh Hieronymus wrote: ... > Second, is there a tutorial > serves as a gentle introduction to Python scripting for LyX? I've not > worked with Python and C++ in the same project before, so I'm not really > sure how to get them to work together, especially when you con

questions about using Doxygen and Python scripting

, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not worked with Python and C++ in the same project before, so I'm not really sure how to get them to work together, especially when you consider issues like type checking, namespaces, header files, and so on. Thanks, Josh

Re: questions about using Doxygen and Python scripting

nice pictures as well. the different parts of code are all related. Second, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not No. What do you need python for btw? Pavel

Re: questions about using Doxygen and Python scripting

an easier time knowing how make doxydoc, if you have graphviz, you will get nice pictures as well. the different parts of code are all related. Second, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not No. What do you need python for btw? Pavel Since

Re: questions about using Doxygen and Python scripting

Josh Hieronymus wrote: Since an ePub file is pretty much a zipped file with XHTML and a few simple files, I was thinking that it might be easiest to use Python to create them. If it comes to packing you might be interested to see our lyxpak.py script. I'm not sure what you mean by 'create';

Re: questions about using Doxygen and Python scripting

On Sun, Jul 21, 2013 at 10:19 PM, Pavel Sanda sa...@lyx.org wrote: Josh Hieronymus wrote: Since an ePub file is pretty much a zipped file with XHTML and a few simple files, I was thinking that it might be easiest to use Python to create them. If it comes to packing you might be

Re: questions about using Doxygen and Python scripting

Josh Hieronymus wrote: I was thinking of using the existing C++ routines to generate the XHTML, and then using Python to generate the additional necessary files, which are mostly XML files with metadata and manifest info, as well as to pack the files. My point was just that you shouldn't use

Re: questions about using Doxygen and Python scripting

Pavel Sanda wrote: we already have working library for zipping files as a part of LyX and commit history might even contain much more generic solution written some time back by Bo Peng as a part of bundled lyx format feature (and reverted later;). You can check commits around

questions about using Doxygen and Python scripting

, is there a tutorial serves as a gentle introduction to Python scripting for LyX? I've not worked with Python and C++ in the same project before, so I'm not really sure how to get them to work together, especially when you consider issues like type checking, namespaces, header files, and so on. Thanks, Josh

Re: questions about using Doxygen and Python scripting

hviz, you will get nice pictures as well. > the different parts of code are all related. Second, is there a tutorial > serves as a gentle introduction to Python scripting for LyX? I've not No. What do you need python for btw? Pavel

Re: questions about using Doxygen and Python scripting

think it would really help me have an easier time knowing how > > make doxydoc, if you have graphviz, you will get nice pictures as well. > > > the different parts of code are all related. Second, is there a tutorial > > serves as a gentle introduction to Python scripting for Ly

Re: questions about using Doxygen and Python scripting

Josh Hieronymus wrote: > Since an ePub file is pretty much a zipped file with XHTML and a few simple > files, I was thinking that it might be easiest to use Python to create > them. If it comes to packing you might be interested to see our lyxpak.py script. I'm not sure what you mean by 'create';

Re: questions about using Doxygen and Python scripting

On Sun, Jul 21, 2013 at 10:19 PM, Pavel Sanda wrote: > Josh Hieronymus wrote: > > Since an ePub file is pretty much a zipped file with XHTML and a few > simple > > files, I was thinking that it might be easiest to use Python to create > > them. > > If it comes to packing you might

Re: questions about using Doxygen and Python scripting

Josh Hieronymus wrote: > I was thinking of using the existing C++ routines to generate the XHTML, > and then using Python to generate the additional necessary files, which are > mostly XML files with metadata and manifest info, as well as to pack the > files. My point was just that you shouldn't

Re: questions about using Doxygen and Python scripting

Pavel Sanda wrote: > we already have working library for zipping files as a part of LyX and commit > history might even contain much more generic solution written some time back > by > Bo Peng as a part of bundled lyx format feature (and reverted later;). You can check commits around

Re: Scripting vs plugins (was RE: Goals for 2.1)

think this is fundamental if we want to hope in third party cooperation. I had a similar idea to record/replay such LFUNs series, especially for reproducing bug it could be useful. Sure, scripting and macro are strictly related. Record a macro would be very simple as each user interaction with LyX

RE: Scripting vs plugins (was RE: Goals for 2.1)

const x11_name = split(to_utf8(cmd.argument()), lyx_name, ' '); ... LFUN arguments are used as a unique string by LFUN implementation itself, it would require a lot of rewrite to change this. In my idea the scripting won't be something like: lfun(lyx-command argument 123

RE: Scripting vs plugins (was RE: Goals for 2.1)

and memory footprint even more. An example would be the parsing of the unicodesymbols file. Weren't we talking about scripting? However seems hard that making something in an interpreted language could improve performances compared with (good) C++. venom00 P.S. Please use this thread.

Re: Scripting vs plugins

of the LyX binary. We already require Python, that's a point in its favour. If we are talking about external tools, yes. But it is also about requiring vs. embedding. For Python scripting, I have written a PyClient package http://wiki.lyx.org/Tools/PyClient that I would welcome to see adopted

Re: Scripting vs plugins

On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote: On 2011-05-06, venom00 wrote: Lua + small and fast, + used in LuaTeX, so it will become more common and known in the TeX community, + a Lua interpreter can be embedded in LyX with minimal impact on

Re: Scripting vs plugins (was RE: Goals for 2.1)

think this is fundamental if we want to hope in third party cooperation. I had a similar idea to record/replay such LFUNs series, especially for reproducing bug it could be useful. Sure, scripting and macro are strictly related. Record a macro would be very simple as each user interaction with LyX

RE: Scripting vs plugins (was RE: Goals for 2.1)

most of the LFUNs don't take arguments or frequently they're text. Do we really want make such a big change just for LFUNs taking numbers? Consider the following LFUN: case LFUN_SET_COLOR: { string lyx_name; string const x11_name = split(to_utf8(cmd.argument()), lyx_name, ' '); ... LFUN argume

RE: Scripting vs plugins (was RE: Goals for 2.1)

re Python, that's a point in its favour. > > Or did I get it wrong? ;) > > The idea is to outsource¹ tasks. This would reduce the binary size and > memory footprint even more. An example would be the parsing of the > unicodesymbols file. Weren't we talking about scripting? Howe

Re: Scripting vs plugins

000 lines of C. Under Linux, the Lua interpreter >> built with all standard Lua libraries takes 153K and the Lua library >> takes 203K. >> Compare this to a minimal Python installation or the size of the LyX >> binary. > We already require Python, that's a point in it

Re: Scripting vs plugins

On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote: > On 2011-05-06, venom00 wrote: > >> >> Lua > >> >>+ small and fast, > >> >>+ used in LuaTeX, so it will become more common and known in the > >> >> TeX community, > >> >>+ a Lua interpreter can be embedded in LyX with

Scripting vs plugins (was RE: Goals for 2.1)

Jean Marc said: The problem with script plugins is that people seem to expect that by linking LyX to python everybody will be able to write python scritps that can manipulate LyX objects natively. I may be missing most of current advancement in programming tools, but I do not see how

Re: Scripting vs plugins (was RE: Goals for 2.1)

On 05.05.2011 19:26, venom00 wrote: Jean Marc said: The problem with script plugins is that people seem to expect that by linking LyX to python everybody will be able to write python scritps that can manipulate LyX objects natively. I may be missing most of current advancement in programming

RE: Scripting vs plugins (was RE: Goals for 2.1)

to hope in third party cooperation. I had a similar idea to record/replay such LFUNs series, especially for reproducing bug it could be useful. Sure, scripting and macro are strictly related. Record a macro would be very simple as each user interaction with LyX goes through a LyX user

Scripting vs plugins (was RE: Goals for 2.1)

Jean Marc said: > The problem with script plugins is that people seem to expect that by > linking LyX to python everybody will be able to write python scritps > that can manipulate LyX objects natively. > > I may be missing most of current advancement in programming > tools, but I > do not

Re: Scripting vs plugins (was RE: Goals for 2.1)

On 05.05.2011 19:26, venom00 wrote: Jean Marc said: The problem with script plugins is that people seem to expect that by linking LyX to python everybody will be able to write python scritps that can manipulate LyX objects natively. I may be missing most of current advancement in programming

RE: Scripting vs plugins (was RE: Goals for 2.1)

is fundamental if we want to hope in > third party cooperation. > > I had a similar idea to record/replay such LFUNs series, > especially for reproducing bug it could be useful. Sure, scripting and macro are strictly related. Record a macro would be very simple as each user intera

RE: Python scripting

, my idea was to add python scripting in-process. The script should be able to register to an event, call LFUN and receive responses, nothing more. Maybe we'll need to add some LFUN to get the selected text, or the whole document source, because I couldn't find such functions in LyXAction.cpp [1]. I

Re: Python scripting

just suggest that people hang around for a while with small things to get idea about the code, otherwise big parts of their code would need rewrite... So, my idea was to add python scripting in-process. The script should be able to register to an event, call LFUN and receive responses, nothing

RE: Python scripting

it means untrivial ditching into the dispatch mechanism, so this is for sure not 2.0 business. OK, then I'll just start thinking about it. Maybe a first release of the scripting support could not have such events, but just keypresses as notification in LyX server. I don't know how these things

RE: Python scripting

elpful! So, my idea was to add python scripting in-process. The script should be able to register to an event, call LFUN and receive responses, nothing more. Maybe we'll need to add some LFUN to get the selected text, or the whole document source, because I couldn't find such functions in LyXAction.

Re: Python scripting

h kind of rules. we just suggest that people hang around for a while with small things to get idea about the code, otherwise big parts of their code would need rewrite... > So, my idea was to add python scripting in-process. The script should be able > to > register to an event, call LF

RE: Python scripting

> it means untrivial ditching into the dispatch mechanism, so this is for sure not > 2.0 business. OK, then I'll just start thinking about it. Maybe a first release of the scripting support could not have such events, but just keypresses as notification in LyX server. I don't kn

Python scripting

Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. I think implementing Python scripting [1] wouldn't be that difficult, as all the functionalities (event notification, commands, response and errors) are already implemented

Re: Python scripting

On 11/26/2010 02:22 PM, veno...@arcadiaclub.com wrote: Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. I think implementing Python scripting [1] wouldn't be that difficult, as all the functionalities (event notification

Re: Python scripting

On 2010-11-26, veno...@arcadiaclub.com wrote: Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. I wrote a Python package that provides an interface via the LyXserver pipes. It's available for download via the LyX wiki http

Re: Python scripting

veno...@arcadiaclub.com wrote: Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. to give you wider overview, i have been asking about must-have new features for 2.0 each month from early spring and formally closed the gates

Python scripting

Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. I think implementing Python scripting [1] wouldn't be that difficult, as all the functionalities (event notification, commands, response and errors) are already implemented

Re: Python scripting

On 11/26/2010 02:22 PM, veno...@arcadiaclub.com wrote: Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have feature missing: support for scripting. I think implementing Python scripting [1] wouldn't be that difficult, as all the functionalities (event notification

Re: Python scripting

On 2010-11-26, <veno...@arcadiaclub.com> wrote: > Hello, LyX 2.0 is getting awesome, but I think there's just a last > must-have feature missing: support for scripting. I wrote a Python package that provides an interface via the LyXserver pipes. It's available for download via the L

Re: Python scripting

veno...@arcadiaclub.com wrote: > Hello, LyX 2.0 is getting awesome, but I think there's just a last must-have > feature missing: support for scripting. to give you wider overview, i have been asking about must-have new features for 2.0 each month from early spring and formally closed the

RE: Scripting fun - removing unneeded headers from source code

...@troubleshooters.com Sent: 07 November 2009 19:19 To: LyX devel lyx-devel@lists.lyx.org Subject: Re: Scripting fun - removing unneeded headers from source code On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote: hi, if there is somebody who would like to contribute to lyx and like to tackle

Re: Scripting fun - removing unneeded headers from source code

John McCabe-Dansted wrote: I have heard that some .h files include other .h files, but are not required to do so by POSIX etc. Thus removing them may harm portability. I am not sure how this could be detected automatically we have to be careful about few headers like cstdlib. then i remember

Re: Scripting fun - removing unneeded headers from source code

On Saturday 07 November 2009 13:37:30 Pavel Sanda wrote: hi, if there is somebody who would like to contribute to lyx and like to tackle with some python/bash scripting, consider fixing the bug http://www.lyx.org/trac/ticket/6305 . pavel Angus has tackled this task years ago. Some

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 07, 2009 at 11:12:06PM +0100, Alex Fernandez wrote: On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt sl...@troubleshooters.com wrote: I'm wondering if there's a less compute intensive method than the brute force method of removing a #include from a .h, and then recompiling every .cpp

Re: Scripting fun - removing unneeded headers from source code

On Sun, Nov 08, 2009 at 12:55:15AM +0100, Vincent van Ravesteijn wrote: Pavel Sanda schreef: Vincent van Ravesteijn wrote: my draft implied one compilation per one #include in our sources, no combinations. the only tweaking part was that detection in .h files - one has to distinguish

Re: Scripting fun - removing unneeded headers from source code

On Sun, Nov 08, 2009 at 11:19:55AM +0800, John McCabe-Dansted wrote: I have heard that some .h files include other .h files, but are not required to do so by POSIX etc. Thus removing them may harm portability. This discussion is not much about C headers. They are comparatively short and above

RE: Scripting fun - removing unneeded headers from source code

;sl...@troubleshooters.com> Sent: 07 November 2009 19:19 To: LyX devel <lyx-devel@lists.lyx.org> Subject: Re: Scripting fun - removing unneeded headers from source code On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote: > hi, > > if there is somebody who would like to contr

Re: Scripting fun - removing unneeded headers from source code

John McCabe-Dansted wrote: > I have heard that some .h files include other .h files, but are not > required to do so by POSIX etc. Thus removing them may harm > portability. I am not sure how this could be detected automatically we have to be careful about few headers like cstdlib. then i

Re: Scripting fun - removing unneeded headers from source code

On Saturday 07 November 2009 13:37:30 Pavel Sanda wrote: > hi, > > if there is somebody who would like to contribute to lyx and like to tackle > with some python/bash scripting, consider fixing the bug > http://www.lyx.org/trac/ticket/6305 . > > pavel Angus has tackle

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 07, 2009 at 11:12:06PM +0100, Alex Fernandez wrote: > On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote: > > I'm wondering if there's a less compute intensive method than the brute > > force > > method of removing a #include from a .h, and then recompiling

Re: Scripting fun - removing unneeded headers from source code

On Sun, Nov 08, 2009 at 12:55:15AM +0100, Vincent van Ravesteijn wrote: > Pavel Sanda schreef: >> Vincent van Ravesteijn wrote: >> my draft implied one compilation per one #include in our sources, no combinations. the only tweaking part was that detection in .h files - one has

Re: Scripting fun - removing unneeded headers from source code

On Sun, Nov 08, 2009 at 11:19:55AM +0800, John McCabe-Dansted wrote: > I have heard that some .h files include other .h files, but are not > required to do so by POSIX etc. Thus removing them may harm > portability. This discussion is not much about C headers. They are comparatively short and

Scripting fun - removing unneeded headers from source code

hi, if there is somebody who would like to contribute to lyx and like to tackle with some python/bash scripting, consider fixing the bug http://www.lyx.org/trac/ticket/6305 . pavel

Re: Scripting fun - removing unneeded headers from source code

On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote: hi, if there is somebody who would like to contribute to lyx and like to tackle with some python/bash scripting, consider fixing the bug http://www.lyx.org/trac/ticket/6305 . pavel Hi Pavel, The part where you remove .h includes

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt sl...@troubleshooters.com wrote: I'm wondering if there's a less compute intensive method than the brute force method of removing a #include from a .h, and then recompiling every .cpp file. I thought about semantic processing: read all the prototypes

Re: Scripting fun - removing unneeded headers from source code

Steve Litt wrote: The part where you remove .h includes from .cpp is dead bang easy if rather slow. Not so with the .h includes inside other .h files. For each #include removal from a .h file, you'd have to compile every .cpp that includes the including .h. my draft implied one

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda schreef: Steve Litt wrote: The part where you remove .h includes from .cpp is dead bang easy if rather slow. Not so with the .h includes inside other .h files. For each #include removal from a .h file, you'd have to compile every .cpp that includes the including .h. my

Re: Scripting fun - removing unneeded headers from source code

Vincent van Ravesteijn wrote: my draft implied one compilation per one #include in our sources, no combinations. the only tweaking part was that detection in .h files - one has to distinguish whether the compilation fails because of header insuficiency in .h or in consequent .cpp which

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda schreef: Vincent van Ravesteijn wrote: my draft implied one compilation per one #include in our sources, no combinations. the only tweaking part was that detection in .h files - one has to distinguish whether the compilation fails because of header insuficiency in .h or in

Re: Scripting fun - removing unneeded headers from source code

Vincent van Ravesteijn wrote: I think you'll mostly remove includes that are redundant in some sense. It's less likely there are huge amounts of costly includes. who knows. i believe that those 13 includes i removed from insetmathhull today were not just redundant of other headers. pavel

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 7, 2009 at 11:12 PM, Alex Fernandez alejandro...@gmail.com wrote: I thought about semantic processing: read all the prototypes in the .h, then see if they are actually used in the .cpp files. Remove those which aren't and try compiling; if the job has been well done then

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda wrote: Vincent van Ravesteijn wrote: I think you'll mostly remove includes that are redundant in some sense. It's less likely there are huge amounts of costly includes. who knows. i believe that those 13 includes i removed from insetmathhull today were not just redundant of

Re: Scripting fun - removing unneeded headers from source code

I have heard that some .h files include other .h files, but are not required to do so by POSIX etc. Thus removing them may harm portability. I am not sure how this could be detected automatically That said I don't know much about this. And even if this is a problem, it presumably would help to

Scripting fun - removing unneeded headers from source code

hi, if there is somebody who would like to contribute to lyx and like to tackle with some python/bash scripting, consider fixing the bug http://www.lyx.org/trac/ticket/6305 . pavel

Re: Scripting fun - removing unneeded headers from source code

On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote: > hi, > > if there is somebody who would like to contribute to lyx and like to tackle > with some python/bash scripting, consider fixing the bug > http://www.lyx.org/trac/ticket/6305 . > > pavel Hi Pavel, The par

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote: > I'm wondering if there's a less compute intensive method than the brute force > method of removing a #include from a .h, and then recompiling every .cpp file. I thought about semantic processing: read all the

Re: Scripting fun - removing unneeded headers from source code

Steve Litt wrote: > The part where you remove .h includes from .cpp is dead bang easy if rather > slow. Not so with the .h includes inside other .h files. For each #include > removal from a .h file, you'd have to compile every .cpp that includes the > including .h. my draft implied one

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda schreef: Steve Litt wrote: The part where you remove .h includes from .cpp is dead bang easy if rather slow. Not so with the .h includes inside other .h files. For each #include removal from a .h file, you'd have to compile every .cpp that includes the including .h. my

Re: Scripting fun - removing unneeded headers from source code

Vincent van Ravesteijn wrote: >> my draft implied one compilation per one #include in our sources, no >> combinations. the only tweaking part was that detection in .h files - one >> has >> to distinguish whether the compilation fails because of header >> insuficiency in >> .h or in consequent

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda schreef: Vincent van Ravesteijn wrote: my draft implied one compilation per one #include in our sources, no combinations. the only tweaking part was that detection in .h files - one has to distinguish whether the compilation fails because of header insuficiency in .h or in

Re: Scripting fun - removing unneeded headers from source code

Vincent van Ravesteijn wrote: > I think you'll mostly remove includes that are redundant in some sense. > It's less likely there are huge amounts of costly includes. who knows. i believe that those 13 includes i removed from insetmathhull today were not just redundant of other headers. pavel

Re: Scripting fun - removing unneeded headers from source code

On Sat, Nov 7, 2009 at 11:12 PM, Alex Fernandez wrote: > I thought about semantic processing: read all the prototypes in the > .h, then see if they are actually used in the .cpp files. Remove those > which aren't and try compiling; if the job has been well done then >

Re: Scripting fun - removing unneeded headers from source code

Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > I think you'll mostly remove includes that are redundant in some sense. > > It's less likely there are huge amounts of costly includes. > > who knows. i believe that those 13 includes i removed from insetmathhull > today were not just

Re: Scripting fun - removing unneeded headers from source code

I have heard that some .h files include other .h files, but are not required to do so by POSIX etc. Thus removing them may harm portability. I am not sure how this could be detected automatically That said I don't know much about this. And even if this is a problem, it presumably would help to

Re: scripting troubles

Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri: What I mean is that I don't think that the renaming work I did can be responsible for this one. IIRC it was more than renaming, otherwise I would not have mentioned it. Georg

Re: scripting troubles

On Sat, Jul 01, 2006 at 12:01:16PM +0200, Georg Baum wrote: Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri: What I mean is that I don't think that the renaming work I did can be responsible for this one. IIRC it was more than renaming, otherwise I would not have mentioned it.

Re: scripting troubles

Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri: > What I mean is that I don't think that the renaming work I did can be > responsible for this one. IIRC it was more than renaming, otherwise I would not have mentioned it. Georg

Re: scripting troubles

On Sat, Jul 01, 2006 at 12:01:16PM +0200, Georg Baum wrote: > Am Freitag, 30. Juni 2006 20:21 schrieb Enrico Forestieri: > > What I mean is that I don't think that the renaming work I did can be > > responsible for this one. > > IIRC it was more than renaming, otherwise I would not have

scripting troubles

atm saved preferences end up in my lyx file! is this related to your recent changes bo? here is a snippet: #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/ \lyxformat 247 \begin_document \begin_header \textclass article \language english \inputencoding auto \font_roman

Re: scripting troubles

Edwin Leuven wrote: here is a snippet: What's wrong with this? Jürgen

Re: scripting troubles

Edwin Leuven wrote: atm saved preferences end up in my lyx file! I don't see any preferences there. If you meant the \font... settings: Have a look at development/FORMAT. Georg

Re: scripting troubles

Edwin Leuven [EMAIL PROTECTED] writes: | atm saved preferences end up in my lyx file! | | is this related to your recent changes bo? | | here is a snippet: | | #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/ | \lyxformat 247 | \begin_document | \begin_header | \textclass

Re: scripting troubles

Juergen Spitzmueller wrote: Edwin Leuven wrote: here is a snippet: What's wrong with this? mmm, it seems i need another coffee didn't look close enough atm i have troubles previewing the document and i somehow connected it to changing preferences (but i was wrong) get an error message:

Re: scripting troubles

Edwin Leuven wrote: atm i have troubles previewing the document and i somehow connected it to changing preferences (but i was wrong) get an error message: file does not exist: c:/tmp/lyx_tmpdir ... /C:_data_newfile8.dvi it doesn't like the semicolon i guess, probably path conversion

Re: scripting troubles

On Fri, Jun 30, 2006 at 03:56:37PM +0200, Georg Baum wrote: Edwin Leuven wrote: atm i have troubles previewing the document and i somehow connected it to changing preferences (but i was wrong) get an error message: file does not exist: c:/tmp/lyx_tmpdir ...

Re: scripting troubles

On Fri, Jun 30, 2006 at 06:51:32PM +0200, Enrico Forestieri wrote: On Fri, Jun 30, 2006 at 03:56:37PM +0200, Georg Baum wrote: Edwin Leuven wrote: atm i have troubles previewing the document and i somehow connected it to changing preferences (but i was wrong) get an error

scripting troubles

atm saved preferences end up in my lyx file! is this related to your recent changes bo? here is a snippet: #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/ \lyxformat 247 \begin_document \begin_header \textclass article \language english \inputencoding auto \font_roman

Re: scripting troubles

Edwin Leuven wrote: > here is a snippet: What's wrong with this? Jürgen

Re: scripting troubles

Edwin Leuven wrote: > atm saved preferences end up in my lyx file! I don't see any preferences there. If you meant the \font... settings: Have a look at development/FORMAT. Georg

Re: scripting troubles

Edwin Leuven <[EMAIL PROTECTED]> writes: | atm saved preferences end up in my lyx file! | | is this related to your recent changes bo? | | here is a snippet: | | #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/ | \lyxformat 247 | \begin_document | \begin_header |

Re: scripting troubles

Juergen Spitzmueller wrote: Edwin Leuven wrote: here is a snippet: What's wrong with this? mmm, it seems i need another coffee didn't look close enough atm i have troubles previewing the document and i somehow connected it to changing preferences (but i was wrong) get an error message:

Re: scripting troubles

Edwin Leuven wrote: > atm i have troubles previewing the document and i somehow connected it > to changing preferences (but i was wrong) > > get an error message: > > file does not exist: > c:/tmp/lyx_tmpdir ... /C:_data_newfile8.dvi > > it doesn't like the semicolon i guess, probably path

  1   2   3   >