> Lazy Generation of LyXText
I like lazy generation.
Also, your proposal seems fine.
A few thoughts:
- I have always wanted to do probabilistic formatting.
The reason it takes 15 seconds to format the user guide is that
the formatting is linear in number of characters, and doing the
Unfortunately, I have no other MS Windows X-servers with which to test
this. As I mentioned, there is no problem when I am working directly on a
UNIX (solaris or linux) machine with a native X-server.
I think you have confused window manager and X server.
I don't want you to try another X
> Unfortunately, I have no other MS Windows X-servers with which to test
> this. As I mentioned, there is no problem when I am working directly on a
> UNIX (solaris or linux) machine with a native X-server.
I think you have confused window manager and X server.
I don't want you to try another
When running LyX for the first time, through XWinPro, I cannot get the
pop-up window that asks to create a new directory called ".lyx". The
program simply sits there waiting for input, and NOT running the
"configure" script.
Could you please try to change to a different window manager, and
The main reason that I want this change ("the red dot") is for the RTL support:
I recognize that there is a problem here, because the cursor has to
have direction as well as position. When you use the mouse, you only
specify position, and therefore the direction is unspecified at the
borders.
> When running LyX for the first time, through XWinPro, I cannot get the
> pop-up window that asks to create a new directory called ".lyx". The
> program simply sits there waiting for input, and NOT running the
> "configure" script.
Could you please try to change to a different window manager,
> The main reason that I want this change ("the red dot") is for the RTL support:
I recognize that there is a problem here, because the cursor has to
have direction as well as position. When you use the mouse, you only
specify position, and therefore the direction is unspecified at the
borders.
[Figinset]
Ok, it is looks ok I'll just apply it. However note that I really
don't want this cleaned up, I want it rewritten!
It might be a good idea to clean it up in order to understand what
is going on. Then you have a better fundation for the rewrite --
in a dual sense: You want to do the
I've looked for your kernel in the 'lyx' cvs module, but the code there is
incomplete. Is there a working version of your kernel? Is it still the plan
to use it instead of the current kernel? When?
The kernel in the cvs module is what there is, besides some documentation
which I'm not sure
[Change of font data structure to be a sorted list and use special characters
to represent font change points]
More discussion:
The change will increase memory consumption, although only minimally.
Regarding the argument that it will be possible to get the proper font
change by being able to
[Figinset]
> Ok, it is looks ok I'll just apply it. However note that I really
> don't want this cleaned up, I want it rewritten!
It might be a good idea to clean it up in order to understand what
is going on. Then you have a better fundation for the rewrite --
in a dual sense: You want to do
> I've looked for your kernel in the 'lyx' cvs module, but the code there is
> incomplete. Is there a working version of your kernel? Is it still the plan
> to use it instead of the current kernel? When?
The kernel in the cvs module is what there is, besides some documentation
which I'm not sure
> [Change of font data structure to be a sorted list and use special characters
> to represent font change points]
More discussion:
The change will increase memory consumption, although only minimally.
Regarding the argument that it will be possible to get the proper font
change by being able
There is also something else that recently was put forward by Meyers:
- functions that are not friends and not class methods makes
encapsulation better and thus maintence easier.
This is one of the main lessons from STL.
Also, this is the principle the new kernel heeded:
The kernel
> There is also something else that recently was put forward by Meyers:
>
> - functions that are not friends and not class methods makes
> encapsulation better and thus maintence easier.
This is one of the main lessons from STL.
Also, this is the principle the new kernel heeded:
The
Kevin Would it be possible to release the ispell specific parts of
Kevin spellchecker.C under the LGPL. Since it doesn't look like any
Kevin of the LyX developers have the time, I decided to create the
Kevin ispell module myself. Since I know very little about working
Kevin with a pipe I
> Kevin> Would it be possible to release the ispell specific parts of
> Kevin> spellchecker.C under the LGPL. Since it doesn't look like any
> Kevin> of the LyX developers have the time, I decided to create the
> Kevin> ispell module myself. Since I know very little about working
> Kevin> with a
Also, one night I filled my disk quota on the network and lost my whole
thesis, emergency file and all! I sniffed around in the /tmp directory and
found all but 2 hours of my work save and sound in a .tex file. A simple
import Tex file and I was up and running again.
I can't thank all of
I haven't been watching closely this discussion, so I want to ask about the
"number attribute" I want to add (for markup of numbers in Right-to-Left text).
Should I implement it (for now) by adding a new field to the LyXFont class?
(actually, I've already done this, so if this is the
> Also, one night I filled my disk quota on the network and lost my whole
> thesis, emergency file and all! I sniffed around in the /tmp directory and
> found all but 2 hours of my work save and sound in a .tex file. A simple
> import Tex file and I was up and running again.
>
> I can't thank
> I haven't been watching closely this discussion, so I want to ask about the
> "number attribute" I want to add (for markup of numbers in Right-to-Left text).
> Should I implement it (for now) by adding a new field to the LyXFont class?
> (actually, I've already done this, so if this is the
It was my mistake here, not to make the meaning of word clear in the context.
Second attempt, is this clear now? ;)
Yes.
I think it's more important to recognize the similarity with font attributes,
just like HTML does with the span property, and thus reduce complexity.
In the
I'm aware of the difference between attribute and elements (tags).
And I know this represents different ways to deal with specialization.
I don't think there a prefered way, it is always a matter of compromisse.
Something like templates vs class hierarchy.
Yes.
One question before
Thank you for the taking you time to answer this. :)
I have to, in order to avoid you guys reinventing the wheel.
I forgot to argue why we should adopt the character attribute
approach *now* for all kinds of attributes: Since the future kernel
uses this approach, we will be much better off
> It was my mistake here, not to make the meaning of word clear in the context.
> Second attempt, is this clear now? ;)
Yes.
> > I think it's more important to recognize the similarity with font attributes,
> > just like HTML does with the property, and thus reduce complexity.
>
> In
> I'm aware of the difference between attribute and elements (tags).
> And I know this represents different ways to deal with specialization.
>
> I don't think there a prefered way, it is always a matter of compromisse.
> Something like templates vs class hierarchy.
Yes.
> One question before
> > Thank you for the taking you time to answer this. :)
>
> I have to, in order to avoid you guys reinventing the wheel.
I forgot to argue why we should adopt the character attribute
approach *now* for all kinds of attributes: Since the future kernel
uses this approach, we will be much better
First, if you haven't noticed, version 1.1.5cvs uses
"\SpecialChar \protected_separator\n" (2)
whereas previous versions used
"\n\protected_separator\n" (1)
My suggestion is to use
"\SpecialChar ~\n" (3)
Using (3) may break lyx2* converters. The
Maybe I wasn't clear (that isn't difficult ;) I am not against the char resolution
attributes, I simply think that we should have middle range attributes that are
perhaps best descrived as insets. And logical structures as Contry or Name should
be one of those cases.
Clear now?
No,
> First, if you haven't noticed, version 1.1.5cvs uses
>"\SpecialChar \protected_separator\n" (2)
> whereas previous versions used
>"\n\protected_separator\n" (1)
> My suggestion is to use
>"\SpecialChar ~\n" (3)
> Using (3) may break lyx2*
> Maybe I wasn't clear (that isn't difficult ;) I am not against the char resolution
> attributes, I simply think that we should have middle range attributes that are
> perhaps best descrived as insets. And logical structures as Contry or Name should
> be one of those cases.
>
> Clear now?
[Properties of individual characters or words]
After some reflection I think that contry is a bad example, most of the
regular logical attributes should be word related and thus some sort of (simple)
inset, and not font related.
Will this simplify the underlying architecture?
I can
Not really. I wasn't planning on using raw_format forever. Only until
someone found time to make a text_format or xml_format that could be input
as well as output -- this would also be more easily read/written by
scripts and other LyXServer apps.
I think we should just switch to
Why a protected separator is encoded as "\SpecialChar \protected_separator"
and not "\SpecialChar ~" ?
The latter is shorter, and it is more consistent to the encoding of other
special chars (\SpecialChar \- or \SpecialChar \@.)
I suspect the only reason is historical.
However, to keep
[Properties of individual characters or words]
> After some reflection I think that contry is a bad example, most of the
> regular logical attributes should be word related and thus some sort of (simple)
> inset, and not font related.
>
> Will this simplify the underlying architecture?
I
> Not really. I wasn't planning on using raw_format forever. Only until
> someone found time to make a text_format or xml_format that could be input
> as well as output -- this would also be more easily read/written by
> scripts and other LyXServer apps.
I think we should just switch to
> Why a protected separator is encoded as "\SpecialChar \protected_separator"
> and not "\SpecialChar ~" ?
> The latter is shorter, and it is more consistent to the encoding of other
> special chars (\SpecialChar \- or \SpecialChar \@.)
I suspect the only reason is historical.
However, to keep
I think you are confusing me with someone else, and certainly you are
refering to XML not to that XTL. ;)
You are not the only José in the world ;-)
The guy that maintains XTL is also called José.
Greets,
Asger
BTW: Are you coming to Norway?
> I think you are confusing me with someone else, and certainly you are
> refering to XML not to that XTL. ;)
You are not the only José in the world ;-)
The guy that maintains XTL is also called José.
Greets,
Asger
BTW: Are you coming to Norway?
I can't remember why XTL insists on using long long -- the documentation
is at my fingertips but I just can't seem to reach it... Just one of those
long hot Australian summer days (but wait it's supposed to autumn now! --
roll on global-warming!)
XTL does not insist on using long long.
If
can you propose a (temporary?) hack to get around these xtl
compile problems that I'm suffering from.
What errors do you get?
Greets,
Asger
Asger, at the moment I'm figuring I'll arrive sometime of the 7th. How
and when were planning on travelling to Stokke? I'll come with you. I
want to arrive the day you've planned to leave then...
That's great!
I think we will catch the ferry to Oslo. It takes longer than the plane,
and
> I can't remember why XTL insists on using long long -- the documentation
> is at my fingertips but I just can't seem to reach it... Just one of those
> long hot Australian summer days (but wait it's supposed to autumn now! --
> roll on global-warming!)
XTL does not insist on using long long.
> can you propose a (temporary?) hack to get around these xtl
> compile problems that I'm suffering from.
What errors do you get?
Greets,
Asger
> Asger, at the moment I'm figuring I'll arrive sometime of the 7th. How
> and when were planning on travelling to Stokke? I'll come with you. I
> want to arrive the day you've planned to leave then...
That's great!
I think we will catch the ferry to Oslo. It takes longer than the plane,
and
The default command for exporting html with tth is
tth -t '$$FName' '$$OutName'
However, it should be
tth -t -L`basename '$$FName' .tex` '$$FName' '$$OutName'"
(with the latter, tth can convert the bibliography, do correct reference etc.)
This has an effect only if
> The default command for exporting html with tth is
> tth -t < '$$FName' > '$$OutName'
> However, it should be
> tth -t -L`basename '$$FName' .tex` < '$$FName' > '$$OutName'"
> (with the latter, tth can convert the bibliography, do correct reference etc.)
>
> This has an effect only
Please look it over and let me know what you think as far as it being
suitable for use in LyX. Thanks.
It is suitable for LyX, as far as I can tell.
My main critique is not regarding the design as such, but rather
that it is not modern C++.
I realize that you have your reasons to do so
Also, I would suggest that all classes be made assignable such
that memory management is simplified. There is no reason that the
user of this library has to fiddle with new and delete.
Could you elaborate on this.
Every class should define these methods:
class Foo {
public:
//
> Please look it over and let me know what you think as far as it being
> suitable for use in LyX. Thanks.
It is suitable for LyX, as far as I can tell.
My main critique is not regarding the design as such, but rather
that it is not modern C++.
I realize that you have your reasons to do so
> > Also, I would suggest that all classes be made assignable such
> > that memory management is simplified. There is no reason that the
> > user of this library has to fiddle with new and delete.
>
> Could you elaborate on this.
Every class should define these methods:
class Foo {
public:
[Rewrite the loading parsing logic]
If you want, I can do the changes (and also do the changes I suggested
for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for
[Rewrite the loading parsing logic]
> If you want, I can do the changes (and also do the changes I suggested
> for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for
Dekel However, the real problem lies on parsing .lyx files at
Dekel Buffer::readLyXformat2 which is done using if-else statements
Dekel (... else if (token == "\\emph") ... ) This is very
Dekel inefficient!
Yes, this code should use LyxLex correctly.
Actually, this is not a real problem
> Dekel> However, the real problem lies on parsing .lyx files at
> Dekel> Buffer::readLyXformat2 which is done using if-else statements
> Dekel> (... else if (token == "\\emph") ... ) This is very
> Dekel> inefficient!
>
> Yes, this code should use LyxLex correctly.
Actually, this is not a real
True. But a lot of trouble can be saved by using things like yacc...
Yacc is complex and error-prone.
It adds comparably much complexity to things. Also, Yacc by itself
does not cut it. You have to bring in the smaller cousin Lex, or Bison
if you are so inclined.
However, that complicates
> True. But a lot of trouble can be saved by using things like yacc...
Yacc is complex and error-prone.
It adds comparably much complexity to things. Also, Yacc by itself
does not cut it. You have to bring in the smaller cousin Lex, or Bison
if you are so inclined.
However, that complicates
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
The best format is the raw format, since it's minimalistic and the
fastest. We don't need interoperability with external sources, so
the raw format is the best solution.
That was what I thought the plain text was. The version I
It has been about a week now and no one has given me any feedback on the
interface. If it is because It was sent as I coded attachment I am
sorry I didn't mean for it be be encoded and I can send it again uncoded.
If it is that you just don't have time fine. I can wait. But please
don't
[XTL]
I did that too and I admit I dont get what this is suposed to do for LyX? Do
you intend to have a new file format?
Btw XDR is a platform independent format for binary representation. I use
XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
some automatized
> On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> > The best format is the raw format, since it's minimalistic and the
> > fastest. We don't need interoperability with external sources, so
> > the raw format is the best solution.
>
> That was wh
> It has been about a week now and no one has given me any feedback on the
> interface. If it is because It was sent as I coded attachment I am
> sorry I didn't mean for it be be encoded and I can send it again uncoded.
>
> If it is that you just don't have time fine. I can wait. But please
>
[XTL]
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
> Btw XDR is a platform independent format for binary representation. I use
> XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
> some
I am intending to make XTL a part of the rae branch sometime this week as
I want to try it out communication with LyXFunc. I'll have to get the
latest release to see what's new. The version I have exports to plain
text but doesn't import from it. It seems very fast for CORBA and XDF(?)
> I am intending to make XTL a part of the rae branch sometime this week as
> I want to try it out communication with LyXFunc. I'll have to get the
> latest release to see what's new. The version I have exports to plain
> text but doesn't import from it. It seems very fast for CORBA and XDF(?)
After some verification of dates, I have come up with this:
Second weekend in June will be just perfect.
(9.-11. + one day on each side if wanted)
We will have the meeting in Stokke, in my parents house.
This time the date is fixed.
I want to confirm that I'm going.
I have reserved
> After some verification of dates, I have come up with this:
>
> Second weekend in June will be just perfect.
> (9.-11. + one day on each side if wanted)
>
> We will have the meeting in Stokke, in my parents house.
>
> This time the date is fixed.
I want to confirm that I'm going.
I have
What I'm looking for is basically any code which could help in this
task:
- a parser for LaTex formulas (we'll probably support a subset of the
whole
LaTex stuff...)
- code to render them on screen (possibly in Qt...)
- code to produce PostScript.
Do you think I may find any of
Ok, I should not have followed up to this mail, but I wanted Asgers
attention...
Hey! I read almost all of the traffic on the list.
[Changes in LyXFont]
Do you have any other/better ideas on how to do this? I think that
after my changes it is a lot clearer what is going on in lowlevel
> What I'm looking for is basically any code which could help in this
> task:
>
> - a parser for LaTex formulas (we'll probably support a subset of the
> whole
> LaTex stuff...)
>
> - code to render them on screen (possibly in Qt...)
>
> - code to produce PostScript.
>
> Do you think I may
> Ok, I should not have followed up to this mail, but I wanted Asgers
> attention...
Hey! I read almost all of the traffic on the list.
[Changes in LyXFont]
> Do you have any other/better ideas on how to do this? I think that
> after my changes it is a lot clearer what is going on in lowlevel
the patch should probably be (at filetools.C:909, in 1.1.4)
last_dot = oldname.rfind('.');
if (last_dot last_slash
last_slash != string::npos
last_dot last_slash )
last_dot = string::npos;
Should I send a true patch? The
> the patch should probably be (at filetools.C:909, in 1.1.4)
>
> last_dot = oldname.rfind('.');
> if (last_dot < last_slash &&
> last_slash != string::npos &&
> last_dot < last_slash )
> last_dot = string::npos;
>
> Should I send a
I confess to being subscribed to the aspell mailing list, so I'm
probably the person Kevin is referring to.
Regarding a generic reusable spell checker interface:
I think the specs were already completed in the old discussion...
What remained in that discussion was just the final synthesis
and
LyXFunc::Dispatch() is a monster if I ever saw one :-)
...
Yes - I see know why Dialogs is necessary though. But somehow I cant stop the
feeling that something is wrong with this design.
What we have chosen to do is to split LyXFunc::Dispatch into separate
dispatchers. We'll have one in
Why the heights of the Combox lists are so small?
For example, in the Citation popup, the list shows only 5 keys at a time,
which makes it very difficult to use if you have large bibliography database.
This can be fixed by changing line 87 of insets/insetbib.C from
bibcombox-add(80, 10,
I confess to being subscribed to the aspell mailing list, so I'm
probably the person Kevin is referring to.
Regarding a generic reusable spell checker interface:
I think the specs were already completed in the old discussion...
What remained in that discussion was just the final synthesis
and
> LyXFunc::Dispatch() is a monster if I ever saw one :-)
...
> Yes - I see know why Dialogs is necessary though. But somehow I cant stop the
> feeling that something is wrong with this design.
What we have chosen to do is to split LyXFunc::Dispatch into separate
dispatchers. We'll have one in
> Why the heights of the Combox lists are so small?
> For example, in the Citation popup, the list shows only 5 keys at a time,
> which makes it very difficult to use if you have large bibliography database.
> This can be fixed by changing line 87 of insets/insetbib.C from
>
I have thought a bit about this, and perhaps we should switch to the
more generally accepted term: "Dialog".
Popups are really something else...
I'm not sure if Allan already did this renaming, but I strongly agree
that we should use the term "dialog".
- work on the painter
> I have thought a bit about this, and perhaps we should switch to the
> more generally accepted term: "Dialog".
> Popups are really something else...
I'm not sure if Allan already did this renaming, but I strongly agree
that we should use the term "dialog".
> - work on the painter
>
Lgb, please apply the Hebrew patch now. Don't wait for 1.1.4.
We are at least three against one, and when you introduce
std::list in the figure code, there is no excuse anymore.
Greets,
Asger
Lgb, please apply the Hebrew patch now. Don't wait for 1.1.4.
We are at least three against one, and when you introduce
std::list in the figure code, there is no excuse anymore.
Greets,
Asger
Actually just as irritating is that the preamble editor quits when pressing
ESC. As a vi man, I tend to do that thoughtlessly :-(
The second patch I submitted to LyX, was a patch that among other things
added ESC as a shortcut to close most dialogs. So I will not be the
person to remove that
- Forwarded message from Michael Schmitt -
From [EMAIL PROTECTED] Thu Jan 20 09:49:34 2000
Return-Path: [EMAIL PROTECTED]
Received: from itm.mu-luebeck.de (wotan.itm.mu-luebeck.de [141.83.21.121])
by vidar.diku.dk (8.9.0/8.9.0) with ESMTP id JAA15422
for [EMAIL
Moreover, I though libxpm was able to dither icons. Am I wrong?
You can argue that humans dither better than machines, so it might
still be relevant to have black/white icons. I don't think it's worth
it, and that was what I meant when I said don't worry about the icons.
Greets,
Asger
What if we just want to drink Norwegian beer?
I'm sure Lgb can find a way to exempt in this case.
Be warned though, beer is NOT cheap in Norway.
Greets,
Asger
What I'd like to see on the other hand is a nice banner and nice icons
when we have more that 256 colors available...
So when do you start drawing?
Greets,
Asger
Can I extend this to a feature request: Life would be made very easy if the
short-cuts to each menu-function were identified on the menu-tabs (as is done
by many other packages). If this is easy to do and someone would hold my hand,
I'll volunteer.
Exactly this feature was implemented at
Can't we make it a free weekend by borrowing in advance from the money we're
going to make on the IPO of LyX, Inc.?
What we could try is to get sponsoring from some open-sourcish firm.
Lgb, maybe you could ask Matthias if Troll Tech could donate a bit of
cash, and we would pay back by paving
> Actually just as irritating is that the preamble editor quits when pressing
> ESC. As a vi man, I tend to do that thoughtlessly :-(
The second patch I submitted to LyX, was a patch that among other things
added ESC as a shortcut to close most dialogs. So I will not be the
person to remove
- Forwarded message from Michael Schmitt -
>From [EMAIL PROTECTED] Thu Jan 20 09:49:34 2000
Return-Path: <[EMAIL PROTECTED]>
Received: from itm.mu-luebeck.de (wotan.itm.mu-luebeck.de [141.83.21.121])
by vidar.diku.dk (8.9.0/8.9.0) with ESMTP id JAA15422
for <[EMAIL
> Moreover, I though libxpm was able to dither icons. Am I wrong?
You can argue that humans dither better than machines, so it might
still be relevant to have black/white icons. I don't think it's worth
it, and that was what I meant when I said don't worry about the icons.
Greets,
Asger
> What if we just want to drink Norwegian beer?
I'm sure Lgb can find a way to exempt in this case.
Be warned though, beer is NOT cheap in Norway.
Greets,
Asger
> What I'd like to see on the other hand is a nice banner and nice icons
> when we have more that 256 colors available...
So when do you start drawing?
Greets,
Asger
> Can I extend this to a feature request: Life would be made very easy if the
> short-cuts to each menu-function were identified on the menu-tabs (as is done
> by many other packages). If this is easy to do and someone would hold my hand,
> I'll volunteer.
Exactly this feature was implemented at
> Can't we make it a free weekend by borrowing in advance from the money we're
> going to make on the IPO of LyX, Inc.?
What we could try is to get sponsoring from some open-sourcish firm.
Lgb, maybe you could ask Matthias if Troll Tech could donate a bit of
cash, and we would pay back by
Disclaimer: I do not speek for the LyX developers.
I have done some investigation into this toolkit myself over the last couple of
days. In fact I think it is the most advanced cross platform toolkit (except
maybe Fltk) but as far as I see, you will be able to do the frames, the dialogs
and
Weelll, ok I do.
My parents are going to Iceland ten days in June, and then we can have
the house,boat,car ... etc. to ourselves.
I'll be more specific later.
What about now ;-)
Do you think it is the start or end of June? I need to know this to
plan in advance, and I'm sure
Well I remember last time we also drunk some wine, well at least Jean-Mark
and myself drunk a bit more of that good stuff, while you and Lars went back
to drinking beer (I remember that around 3 am all of you where happily talking
to local girls too ;). I was astonished how much alcohol you
401 - 500 of 827 matches
Mail list logo
