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
ode or scripting language support.
Just my two cents.
Bo
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
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 LyX to be moved to the
scripting languag
I was wondering, is there a way that it could be possible to generate
box scripts. What I mean by this is, say there was a small feature that
I wanted to add, and it consisted of some latex code with arguments
passed to it. A good example would be this acronym feature. The box
script could l
* 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
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 complete or correct, the author says that many of
the progr
embedded
script as soon as the file is read.
My little analogy should demonstrate why "scripting language != Macro
Virus" in the Unix world. Only a blithering idiot would intentionally
design a program to auto-execute anything whatsoever. I'd like to
think that we on the LyX Team ar
d
to live without:
1) recordability: There should be some ability to record a sequence of
actions, save them in the scripting language, and make them
activatable. For example, a user would likely want to take the
sequence of actions which produce a 3x3 matrix with braces around it,
and the cu
Hi,
It's Friday, so I'll throw my tuppence-worth in here.
Candidates I would consider:
1. Perl. But only because it's free and people know it.
It's a great text-processing language, but it's not
really a control language, which I imagine is the
priority.
2. Javascript. It's pretty s
>
> However, we need to be careful about that new EU parentheses tax . . .
>
> :)
If I read the tax manual correctly, smilies count as 'half of a pair of
paranthesis' if imported from outside the EU. But if used in vegetarian
text, the tax is halved.
Anyway, I'd rather have something easy to r
lars lamented,
> *Mate Wierdl writes:
> | Ah, I read the thread. My question was what was the objection to
> | Scheme here on *this* list.
> I have none.
> Asger things it has complicated syntax for beginners.
The fact that I was able to sit down and start using it in an afternoon
sugges
*Mate Wierdl writes:
| Ah, I read the thread. My question was what was the objection to
| Scheme here on *this* list.
I have none.
Asger things it has complicated syntax for beginners.
Lgb
*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
On Fri, Dec 11, 1998 at 07:19:04PM -0500, Cedric Puddy wrote:
> On Fri, 11 Dec 1998, Mate Wierdl wrote:
> http://icemcfd.com/tcl/comparison.html
> >
> > Looks very interesting. The GNU people seem to have made up their mind(s).
> > What was the objection against scheme here?
> >
> > ---
>
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
Hi,
My 5 cents.
What about a C/C++ interpreter as a scripting engine ?
Have a look at CINT :
http://root.cern.ch/root/Cint.html
Jacek.
y first programming words in basic, as a child; oh sweet
memories!!!
And to be consistent with our new official scripting language,
we should switch the source code to fortran, to make happy
my grandfather.
Alejandro
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
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 somethi
> "José" == José Abílio de Oliveira Matos <[EMAIL PROTECTED]> writes:
José> I prefer Python, since its gracefull, simple, really neat and
José> it does what I expect to :-().
José> FYI, all the users of sgmltools ( the GPL tools that provide
José> the support for docbook document process
ouisa Street, Kitchener, Ontario, N2H 5M3, 519-884-0701
\
Cedric Puddy, IS Director[EMAIL PROTECTED]
PGP Key Available at: http://www.thinkers.org/cedric
On Fri, 11 Dec 1998, Asger K. Alstrup Nielsen wrote:
> It seems that
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 gracefull
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Yabasic. A basic variant that's GPL.
Asger> http://www.online.de/home/ihm/basic.htm
Asger> I don't know how much work there is in adapting it. It
Asger> features some things we don't need, such as graphics and
Asger>
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 needs.
I've done a bit of searching and so far found one candidate language
Hi all,
I have followed this thread with interest despite my busy, busy agenda :(
Although I really like Perl5, maybe precisely for the powerful different
constructions it allows to solve the same problem (it's easier to fit the
way the programmer/user think about that problem) I can see a probl
39 matches
Mail list logo
