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
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
>> >> the binary size.
>> > Wasn't there anothe
> >> 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
> >> the binary size.
>
> > Wasn't there another thread with the result that LyX is
> I think I have quite an uncommon opinion (among LyX developers) about
> what LFUNs are causing (perhaps as a side effect) in the LyX code.
> Basically, many classes use this machinery to invoke operations, with
> the result that sometimes the class does not get a properly designed
> interface
Il 05/05/2011 22:40, venom00 ha scritto:
My idea was to issue commands to LyX via LFUNs, which are
quite stable, even because they're associated with
customizable shortcuts. I think this is a very uninvasive approach.
For the language I prefer Python because _a lot_ of people
uses it and I thi
> > My idea was to issue commands to LyX via LFUNs, which are
> quite stable, even because they're associated with
> customizable shortcuts. I think this is a very uninvasive approach.
> > For the language I prefer Python because _a lot_ of people
> uses it and I think this is fundamental if we
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
to
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 abov
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
>>
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 every .cpp
> > file.
>
> I
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. Som
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
November 2009 19:19
To: LyX devel
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
> with some python/bash scripti
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 kno
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 redunda
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
> compilation should proceed wi
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
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 cons
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 .cp
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 d
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 compila
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 prototypes in the
.h, then see if th
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 inclu
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
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
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)
> > >
> > >
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 ... /C:_d
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 conv
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:
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
| \textclas
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
Edwin Leuven wrote:
> here is a snippet:
What's wrong with this?
Jürgen
Bo Peng wrote:
The .lyx format is not really working. One can, e.g. not use
'real' text within math, which makes implementing e.g. \mbox
impossible.
There must be some good reasons to change .lyx format, and switch to
unicode. But those reasons are invisible to normal users like me. All
On Sat, Apr 01, 2006 at 09:13:17AM -0600, Bo Peng wrote:
> > The .lyx format is not really working. One can, e.g. not use
> > 'real' text within math, which makes implementing e.g. \mbox
> > impossible.
>
> There must be some good reasons to change .lyx format, and switch to
> unicode. But those r
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > The .lyx format is not really working. One can, e.g. not use
| > 'real' text within math, which makes implementing e.g. \mbox
| > impossible.
|
| There must be some good reasons to change .lyx format, and switch to
| unicode. But those reasons are invisib
> The .lyx format is not really working. One can, e.g. not use
> 'real' text within math, which makes implementing e.g. \mbox
> impossible.
There must be some good reasons to change .lyx format, and switch to
unicode. But those reasons are invisible to normal users like me. All
I can see is that I
On Fri, Mar 31, 2006 at 06:49:41AM -0600, Bo Peng wrote:
> > Think *unicode* and forget about this one for now.
>
> If you ask me what are the most important features I have in mind. I
> would say: NO more new features. If .lyx format is working, why XML?
> If current foreign language support is f
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> If current foreign language support is fine, why unicode?
The problem is that it is not fine, it is a hack.
JMarc
> Think *unicode* and forget about this one for now.
If you ask me what are the most important features I have in mind. I
would say: NO more new features. If .lyx format is working, why XML?
If current foreign language support is fine, why unicode?
Let us clear up all existing bugs and make lyx *
Charles de Miramon wrote:
> I'm not a developper but I'm wondering if you are not underestimating the
> complexity of going Unicode.
I don't think so.
> Changing the internal format to Unicode is
> maybe not that hard but having a fully Unicode editor is *very* complex.
And the latter is not t
On Fri, 2006-03-31 at 12:34 +0200, Charles de Miramon wrote:
> Lars Gullik Bjønnes wrote:
>
> >
> > Think *unicode* and forget about this one for now.
> >
>
> I'm not a developper but I'm wondering if you are not underestimating the
> complexity of going Unicode. Changing the internal format to
Lars Gullik Bjønnes wrote:
>
> Think *unicode* and forget about this one for now.
>
I'm not a developper but I'm wondering if you are not underestimating the
complexity of going Unicode. Changing the internal format to Unicode is
maybe not that hard but having a fully Unicode editor is *very* co
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > If we are going for this it will be a major new feature (IMHO) and
| > should then wait for 1.7.
|
| And it needs cleanup of classes like buffer. Anyway, the real
| implementation is *easy* so this feature is not that far away from us.
This feature has a
> If you want to wrap c++ to interface with python, I suggest boost::python.
> It's easy once you get over the learning curve, and we're already using
> boost.
That is true, but I only know SWIG. :-) While SWIG can wrap all the
classes automatically, boost::python need to write things manually
(an
Bo Peng wrote:
>> If we are going for this it will be a major new feature (IMHO) and
>> should then wait for 1.7.
>
> And it needs cleanup of classes like buffer. Anyway, the real
> implementation is *easy* so this feature is not that far away from us.
>
> Bo
If you want to wrap c++ to interfac
> If we are going for this it will be a major new feature (IMHO) and
> should then wait for 1.7.
And it needs cleanup of classes like buffer. Anyway, the real
implementation is *easy* so this feature is not that far away from us.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Dear list,
|
| I just read a bit about 'LyX Wanted Features list' and saw
|
| Scripting language: Support a scripting language to control various
| parts of LyX, this requires deciding on an official scripting
| language. The idea is for non-core parts of
On Tuesday 01 February 2005 15:10, G. Milde wrote:
>
> These are the first to spring into my mind. There are more to expect. But
> also, they (and the existing ones) must be documented in order to be
> usable.
>
> My goal is to get for lyx a broad base of user-provided extensions in the
> way we th
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "G" == G Milde <[EMAIL PROTECTED]> writes:
>
| G> The keybinding is not really needed. If the code becomes more clear
| G> and concise by removing, please do so.
>
| It does not really change the code. It is just a matter of design of
| the l
> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> The keybinding is not really needed. If the code becomes more clear
G> and concise by removing, please do so.
It does not really change the code. It is just a matter of design of
the lyxsever protocol.
G> I thought to keep it for backwards comp
On 2.02.05, Jean-Marc Lasgouttes wrote:
> > "G" == G Milde <[EMAIL PROTECTED]> writes:
>
> G> Feature Request ===
>
> G> Could the lfun "server-notify" take an data argument, that is
> G> passed on to the lyxserver?
>
> Sure. And what about getting rid of the key binding too? Is
> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> Feature Request ===
G> Could the lfun "server-notify" take an data argument, that is
G> passed on to the lyxserver?
Sure. And what about getting rid of the key binding too? Is it really
useful to the client?
JMarc
On 27.01.05, Jose' Matos wrote:
> This is something that I wanted to do for quite some time. :-)
So did I. That's why I'm glad I did it finally.
> PS: In another movement (no pun John ;-) to help python scripting for lyx
> the lyx2lyx program has become only a interface to the new LyX.py modu
On Fri, Jan 28, 2005 at 09:01:04AM +, Angus Leeming wrote:
> > Super-glad to see Asger back into the fold. He can be a less hated me!!
> He's just got a thicker skin ;-) How the hell are you anyway?
Fine, insanity at work has mitigated into mere eccentricity. I might
even build a recent lyx s
John Levon wrote:
> Super-glad to see Asger back into the fold. He can be a less hated me!!
He's just got a thicker skin ;-) How the hell are you anyway?
--
Angus
On Thu, Jan 27, 2005 at 07:03:11PM +, Jose' Matos wrote:
> PS: In another movement (no pun John ;-) to help python scripting for lyx
Is this a test on whether I'm still listening? :)
Super-glad to see Asger back into the fold. He can be a less hated me!!
john
On Friday 21 January 2005 08:28, G. Milde wrote:
>
> Please find attached my work so far. If you copy lyx.py into the
> "pythonpath", pydoc will give you a nice view of the doc strings and
> setup
Hi GÃnter,
I would like to congratulate you for your work with the lyx server via
the
pyt
On 19.01.05, Angus Leeming wrote:
> G. Milde wrote:
> > Dear LyXers,
> >
> > IMHO, LyX clearly lacks a decent support for a scripting language. As
> > this topic is not new but discussion about which language to choose is
> > endless, I tried to set up a script interface via the lyxserver.
>
> De
At 15:04 18.02.02 +0100, you wrote:
>On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> > Is this still up-to-date?
>
>Fairly.
>
> > Or are there plans to do anything using the Lyx-Server? If not, I'd
> glad to
> > implement parts of the
> > the scripting capabilities into Lyx.
>
On Mon, 18 Feb 2002, Andre Poenitz wrote:
> I'd like to have the decision on LyX's favourite scripting language first.
www.lua.org.
Greets,
Asger
> If I make patches to integrate Python directly into Lyx, is there a
> chance that they make it into the official sources? As I can see with my
> current knowledge about the lyx sources and the Python lib, the changes
> to the existing sources will be very little for basic scripting
> functions,
On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> Is this still up-to-date?
Fairly.
> Or are there plans to do anything using the Lyx-Server? If not, I'd glad to
> implement parts of the
> the scripting capabilities into Lyx.
>
> Furhter, I would propose to use Python as scr
On Sat, Feb 16, 2002 at 02:32:05PM +0100, Florian Klaempfl wrote:
> interface for the desired language => the lyx server solution doubles the
> work.
no, not really. It provides a simple one-point place where interaction happens.
If it's really hard to communicate via named pipes in your favour
At 02:28 16.02.02 +, you wrote:
>On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
>
> > Or are there plans to do anything using the Lyx-Server? If not, I'd
> glad to
> > implement parts of the
> > the scripting capabilities into Lyx.
>
>the idea is to sort out the lyxfunc int
On Sat, Feb 16, 2002 at 03:18:41AM +0100, Florian Klaempfl wrote:
> Or are there plans to do anything using the Lyx-Server? If not, I'd glad to
> implement parts of the
> the scripting capabilities into Lyx.
the idea is to sort out the lyxfunc interface (what lyx server uses) so you can
script
* John Levon <[EMAIL PROTECTED]> [010603 01:26]:
>
> I would suggest the simplest solution to this decision is to see what
> gets implemented ... since there aren't that many developers I don't
> really see a problem in choosing a particular language, since there is
> unlikely to be more than one
On Sun, 3 Jun 2001, Baruch Even wrote:
> There was a suggestion to do a shootout between scripting languages. It
> was mostly done already, though not in the context of an embedded
> editor.
>
> Check this site for comparisons: http://www.bagley.org/~doug/shootout/
>
> This is by no means complet
67 matches
Mail list logo
