"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger 1) Sometimes when the window is resized, LyX goes into an
Asger infinite loop and has to be killed by hand.
Ah.
Asger 2) Sometimes, LyX generates wrong LaTeX for something that
Asger worked in 0.12.0. I think it involves $
Ahem, excuse me to come abruptly in the discussion, but how far could
we go by only using only the lyserver and libraries interacing to it
from perl, python, sh, gnuplot, whatever? What would be real gain of
an enbedded language, compared to the development cost (to make it
really useful, I
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger The main problem I see with this approach is that the we will
Asger end up with something similar to handling CGI-scripts in
Asger Web-servers: LyX has to spawn an external interpreter, and this
Asger is slow and insecure.
these days. I think the KOffice word processor might be approaching
milestone 3, but "fortunately", their aim is different than ours:
They want to implement a desktop publishing program.
Wait a minute, I thought klyx *was* the koffice word proccessor . . .
I don't think it is.
Check
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger I'll try to find the details and forward it if I don't have
Asger time to find and squash the bugs myself.
I'll try to have a look if you can't.
JMarc
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars *Jean-Marc Lasgouttes writes: | It seems to me that this will be
Lars needed at least for the GUI parts, | and that it will be more
Lars convenient.
Lars I can't see the easy solution on how to implement that. Where
Lars to install
I imagine that several of the functions in LyXFunc really should be
written using the script language instead. So that we only have the
basic commands implemented in C++ and the compound(?) ones written in
scripts.
I like this approach too.
But for this to work, we need to settle the issue
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger - Which "official" scripting language should we choose?
Asger To me, Python is still the best candiate, but it seems
Asger Alejandro disagrees until more research has been done. That
Asger makes sense to me, so Alejandro, what
[I wrote about LyX document virus]
That's an interesting idea. This would happen if we allow the
documents themselves to contain macros. I think that this is a bad
idea at this point of time.
Yes, but I think we want to aim for this, and therefor, we should
consider this now.
In fact, I'd
Not really. If you use a lot of other non-printable stuff (like '\atop')
the problem remains. I think there must be some way to scroll
horizontally through a table that *is* wider than the screen.
Even a couple of \mapsto leads to the same problem, and those seem to be
quite common at least
A nice solution would be a scripting language which is small enough
to be included in the distribution without major bloat. Does such a
beast exist?
The best candiate for this solution is SIOD: Scheme In One Defun.
It's small and lean, and easily customized for what we need.
The main
Hi,
I have the loonely knight, fighting all the evil ghost of the past ( read
latexdel insets) while you are having all the fun discussing the scripting
language...
Now I need help because I'm not able to advance on my own (at least on a
reasonable time).
I need to do
Andre' Poenitz wrote:
equation, since part of it becomes invisible, and doesn't wrap. This
would be
cured with WYSIWYG boldface inside equations - a nice Xmas present for
users.
As a writer of vectors I would strongly support the request for C-b to
work in equations. What lyx offers
Hi,
I have strong feelings against to introduce another scripting language, one
more language to learn and master if you want to do something.
I think that we should stick to one of the major league script languages
{Perl,Python,Tcl}.
I prefer Python, since its
--- Forwarded Message
Date: Thu, 10 Dec 1998 09:28:56 -0700
From: [EMAIL PROTECTED] (Steve Wampler)
Subject: Re: is icon embaddable
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Mate Wierdl wrote:
I am not sure I can ask the right
asger announced,
3) A third one I forgot, but it was serious as well.
yes, I can confirm this one :)
--
asger added,
But a mail-sender component is not out of the question IMO.
it's already there :)
Export-custom, check postscript, and
a2ps -o -|uuencode | mail |someone@somewhere
sends things to my committee . . .
seriously, though, what more would we want than "mail this document to
On Fri, Dec 11, 1998 at 11:02:13AM +0100, Jean-Marc Lasgouttes wrote:
Hmmm, I think that reLyX should put its temporary files in /tmp just
like any program does. What is your problem with that?
I suppose I could. I assume /tmp is guarantted to exist on any architecture
we're running reLyX
On Fri, Dec 11, 1998 at 12:01:09PM +0100, Andre' Poenitz wrote:
I certainly have not read this list for a while... a newsreader within
LyX? Are you serious? I was under the impression that LyX was intended
to be an easy-to-use front end to LaTeX, not an 'eierlegende
Wollmilchsau'... some
On Fri, Dec 11, 1998 at 03:00:12PM +0100, Asger K. Alstrup Nielsen wrote:
Hi!
It seems that the best for us would be to bundle a scripting
language.
In order to avoid having to implement our own language from
scratch, it might make sense to start with something and
hack that to suit our
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger [I wrote about LyX document virus]
That's an interesting idea. This would happen if we allow the
documents themselves to contain macros. I think that this is a bad
idea at this point of time.
Asger Yes, but I think we want
On Fri, Dec 11, 1998 at 10:13:59AM -0500, Cedric Puddy wrote:
There was a (massive) discussion (featuring
John Ousterhout "the tcl guy" and Richard Stallman
[who seems to be responsible for the GNU architecure!],
and lots of other very knowledgable people) about
Tcl VS. other scripting
Not really. If you use a lot of other non-printable stuff (like '\atop')
the problem remains. I think there must be some way to scroll
horizontally through a table that *is* wider than the screen.
Even a couple of \mapsto leads to the same problem, and those seem to be
quite common at
On Fri, 11 Dec 1998, Asger K. Alstrup Nielsen wrote:
Alejandro disagrees until more research has been done.
That makes sense to me, so Alejandro, what things do you
think we should investigate now to progress further?
The first time we were considering to adopt a new gui toolkit to switch
Thanks for the advice, M-c b is just what I needed for bold in
equations.
I have downloaded the pre4 version of 1 and can see that things are
happening with labels and related items but failed to work out exactly
what. So here is what I would like to do and why but please feel free to
damn me
On Fri, 11 Dec 1998, Mate Wierdl wrote:
On Fri, Dec 11, 1998 at 10:13:59AM -0500, Cedric Puddy wrote:
There was a (massive) discussion (featuring
John Ousterhout "the tcl guy" and Richard Stallman
[who seems to be responsible for the GNU architecure!],
and lots of other very
*Alejandro Aguilar Sierra writes:
| On 10 Dec 1998, Lars Gullik Bjønnes wrote:
|| I want it to be possible for several external programs to connect
|| to the LyX-server(s) at once. Will be similar to multipleviews.
|| (actually lyxserver will be a specialized BufferView)
| Rather BufferView
*Asger K Alstrup Nielsen writes:
| Also, it would naturally add an option for LyX to handle the
| opening of a document from standard in.
I don't think you want 1.0 released. You keep suggestin and wanting to
implement new things all the time...
Lgb
PS. 1.1.x stuff
*Jean-Marc Lasgouttes writes:
| I am not against the principle of using something like python. The
| only thing that annoys me is that, according to what I read, next
| version will require:
|
| - python
|
| - something like t1lib to do Type1 fonts rendering, plus a bunch of
| TeX type1
*Asger K Alstrup Nielsen writes:
| - What technical approach should be adopt - embedment or external
| spawns with communication through pipes or sockets?
the LyX script language should _really_ _really_ be embedded into LyX.
Lgb
*Jean-Marc Lasgouttes writes:
| There have been talks about allowing separate downloads of the
| frontends in the future. I do not see how you can make this
| possible without splitting the po files.
I don't think we should have separate downloads. That will only give
us a hard time
*Jean-Marc Lasgouttes writes:
|
|| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars| *Alejandro Aguilar Sierra writes: | Ahem, we have not yet
Lars| decided for phyton. The point of Lars post, | AIUI, is to
Lars| improve the lyxserver to be able to try it with more | script
Lars|
*Jean-Marc Lasgouttes writes:
| (setq foo bar) (setq blah baz)
Why not? In the future the user will never see the contents of lyxrc
anyway, so we chose something that is easy to parse.
Asger| This problem of syntax is not easily "customized" away in
Asger| Scheme.
| Right.
(as said earlier:
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> 1) Sometimes when the window is resized, LyX goes into an
Asger> infinite loop and has to be killed by hand.
Ah.
Asger> 2) Sometimes, LyX generates wrong LaTeX for something that
Asger> worked in 0.12.0. I think it
> Ahem, excuse me to come abruptly in the discussion, but how far could
> we go by only using only the lyserver and libraries interacing to it
> from perl, python, sh, gnuplot, whatever? What would be real gain of
> an enbedded language, compared to the development cost (to make it
> really
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The main problem I see with this approach is that the we will
Asger> end up with something similar to handling CGI-scripts in
Asger> Web-servers: LyX has to spawn an external interpreter, and this
Asger> is slow and
> > these days. I think the KOffice word processor might be approaching
> > milestone 3, but "fortunately", their aim is different than ours:
> > They want to implement a desktop publishing program.
>
> Wait a minute, I thought klyx *was* the koffice word proccessor . . .
I don't think it is.
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I'll try to find the details and forward it if I don't have
Asger> time to find and squash the bugs myself.
I'll try to have a look if you can't.
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> *Jean-Marc Lasgouttes writes: | It seems to me that this will be
Lars> needed at least for the GUI parts, | and that it will be more
Lars> convenient.
Lars> I can't see the easy solution on how to implement that. Where
Lars>
> I imagine that several of the functions in LyXFunc really should be
> written using the script language instead. So that we only have the
> basic commands implemented in C++ and the compound(?) ones written in
> scripts.
I like this approach too.
But for this to work, we need to settle the
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> - Which "official" scripting language should we choose?
Asger> To me, Python is still the best candiate, but it seems
Asger> Alejandro disagrees until more research has been done. That
Asger> makes sense to me, so
[I wrote about LyX document virus]
> That's an interesting idea. This would happen if we allow the
> documents themselves to contain macros. I think that this is a bad
> idea at this point of time.
Yes, but I think we want to aim for this, and therefor, we should
consider this now.
> In fact,
> Not really. If you use a lot of other non-printable stuff (like '\atop')
> the problem remains. I think there must be some way to scroll
> horizontally through a table that *is* wider than the screen.
> Even a couple of \mapsto leads to the same problem, and those seem to be
> quite common at
> A nice solution would be a scripting language which is small enough
> to be included in the distribution without major bloat. Does such a
> beast exist?
The best candiate for this solution is SIOD: Scheme In One Defun.
It's small and lean, and easily customized for what we need.
The main
Hi,
I have the loonely knight, fighting all the evil ghost of the past ( read
latexdel insets) while you are having all the fun discussing the scripting
language...
Now I need help because I'm not able to advance on my own (at least on a
reasonable time).
I need to do
Andre' Poenitz wrote:
>
> > equation, since part of it becomes invisible, and doesn't wrap. This
> > would be
> > cured with WYSIWYG boldface inside equations - a nice Xmas present for
> > users.
As a writer of vectors I would strongly support the request for C-b to
work in equations. What lyx
Hi,
I have strong feelings against to introduce another scripting language, one
more language to learn and master if you want to do something.
I think that we should stick to one of the major league script languages
{Perl,Python,Tcl}.
I prefer Python, since its
--- Forwarded Message
Date: Thu, 10 Dec 1998 09:28:56 -0700
From: [EMAIL PROTECTED] (Steve Wampler)
Subject: Re: is icon embaddable
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Mate Wierdl wrote:
> I am not sure I can ask the
asger announced,
> 3) A third one I forgot, but it was serious as well.
yes, I can confirm this one :)
--
asger added,
> But a mail-sender component is not out of the question IMO.
it's already there :)
Export->custom, check postscript, and
a2ps -o -|uuencode | mail |someone@somewhere
sends things to my committee . . .
seriously, though, what more would we want than "mail this document to
On Fri, Dec 11, 1998 at 11:02:13AM +0100, Jean-Marc Lasgouttes wrote:
>
> Hmmm, I think that reLyX should put its temporary files in /tmp just
> like any program does. What is your problem with that?
I suppose I could. I assume /tmp is guarantted to exist on any architecture
we're running reLyX
On Fri, Dec 11, 1998 at 12:01:09PM +0100, Andre' Poenitz wrote:
>
> I certainly have not read this list for a while... a newsreader within
> LyX? Are you serious? I was under the impression that LyX was intended
> to be an easy-to-use front end to LaTeX, not an 'eierlegende
> Wollmilchsau'...
On Fri, Dec 11, 1998 at 03:00:12PM +0100, Asger K. Alstrup Nielsen wrote:
> Hi!
>
> It seems that the best for us would be to bundle a scripting
> language.
>
> In order to avoid having to implement our own language from
> scratch, it might make sense to start with something and
> hack that to
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> [I wrote about LyX document virus]
>> That's an interesting idea. This would happen if we allow the
>> documents themselves to contain macros. I think that this is a bad
>> idea at this point of time.
Asger> Yes, but I
On Fri, Dec 11, 1998 at 10:13:59AM -0500, Cedric Puddy wrote:
> There was a (massive) discussion (featuring
> John Ousterhout "the tcl guy" and Richard Stallman
> [who seems to be responsible for the GNU architecure!],
> and lots of other very knowledgable people) about
> Tcl VS. other scripting
> > Not really. If you use a lot of other non-printable stuff (like '\atop')
> > the problem remains. I think there must be some way to scroll
> > horizontally through a table that *is* wider than the screen.
> > Even a couple of \mapsto leads to the same problem, and those seem to be
> > quite
On Fri, 11 Dec 1998, Asger K. Alstrup Nielsen wrote:
> Alejandro disagrees until more research has been done.
> That makes sense to me, so Alejandro, what things do you
> think we should investigate now to progress further?
The first time we were considering to adopt a new gui toolkit to
Thanks for the advice, M-c b is just what I needed for bold in
equations.
I have downloaded the pre4 version of 1 and can see that things are
happening with labels and related items but failed to work out exactly
what. So here is what I would like to do and why but please feel free to
damn me
On Fri, 11 Dec 1998, Mate Wierdl wrote:
> On Fri, Dec 11, 1998 at 10:13:59AM -0500, Cedric Puddy wrote:
>
> > There was a (massive) discussion (featuring
> > John Ousterhout "the tcl guy" and Richard Stallman
> > [who seems to be responsible for the GNU architecure!],
> > and lots of other very
*Alejandro Aguilar Sierra writes:
| On 10 Dec 1998, Lars Gullik Bjønnes wrote:
|| I want it to be possible for several external programs to connect
|| to the LyX-server(s) at once. Will be similar to multipleviews.
|| (actually lyxserver will be a specialized BufferView)
| Rather BufferView
*Asger K Alstrup Nielsen writes:
| Also, it would naturally add an option for LyX to handle the
| opening of a document from standard in.
I don't think you want 1.0 released. You keep suggestin and wanting to
implement new things all the time...
Lgb
PS. 1.1.x stuff
*Jean-Marc Lasgouttes writes:
| I am not against the principle of using something like python. The
| only thing that annoys me is that, according to what I read, next
| version will require:
|
| - python
|
| - something like t1lib to do Type1 fonts rendering, plus a bunch of
| TeX type1
*Asger K Alstrup Nielsen writes:
| - What technical approach should be adopt - embedment or external
| spawns with communication through pipes or sockets?
the LyX script language should _really_ _really_ be embedded into LyX.
Lgb
*Jean-Marc Lasgouttes writes:
| There have been talks about allowing separate downloads of the
| frontends in the future. I do not see how you can make this
| possible without splitting the po files.
I don't think we should have separate downloads. That will only give
us a hard time
*Jean-Marc Lasgouttes writes:
|
|| "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars| *Alejandro Aguilar Sierra writes: | Ahem, we have not yet
Lars| decided for phyton. The point of Lars post, | AIUI, is to
Lars| improve the lyxserver to be able to try it with more | script
*Jean-Marc Lasgouttes writes:
| (setq foo bar) (setq blah baz)
Why not? In the future the user will never see the contents of lyxrc
anyway, so we chose something that is easy to parse.
Asger| This problem of syntax is not easily "customized" away in
Asger| Scheme.
| Right.
(as said earlier:
66 matches
Mail list logo