On Tue, 16 Mar 1999, Asger K. Alstrup Nielsen wrote:
> Allan wrote:
> > Every inset with an associated popup needs to know which buffer it belongs
> > to so the popup can talk to it (eg. get/set data). I haven't given much
> > thought to removing this requirement but I am certainly open to
> > su
On Mon, Mar 22, 1999 at 12:40:10PM +0100, Andre' Poenitz wrote:
> John Weiss wrote:
> > The problem here is that LyX will then either:
> > 1. generate LaTeX code that won't LaTeX.
>
> It could give a warning that it is not able to produce 1:1 LateX and
> can offer a workaround.
>
> > 2.
On Tue, 23 Mar 1999, Asger Alstrup Nielsen wrote:
> > I'd like to see a solution that doesn't require the Writers to maintain a
> > running tally of which fonts are open and what order they were generated
> > in.
>
> I think I need to argue once more why having the font attributes for every
>
> I'd like to see a solution that doesn't require the Writers to maintain a
> running tally of which fonts are open and what order they were generated
> in.
I think I need to argue once more why having the font attributes for every
single character in the document will not cause problems for th
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
> >-- and I think it is more WYSIWYM than telling the user that (s)he
> >cannot mean "nested paragraphs" because there are no such beasts
> >in LyX.
What I wanted to say on this particular point is that 'nested
paragraph'
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
>> The problem here is that LyX will then either: 1. generate LaTeX
>> code that won't LaTeX.
Andre'> It could give a warning that it is not able to produce 1:1
Andre'> LateX and can offer a workaround.
That seems too complicated to
> On Mon, Mar 15, 1999 at 04:07:08PM +0100, Andre' Poenitz wrote:
> > 1. LyX is *more* than a LaTeX frontend, so the excuse "LaTeX can't cope
> >with it (natively), so we can't have it in LyX" might put off people
> >who want do use LyX for HTML or maybe even just for displaying
> >thi
>
> [Unions]
> > That is probably the only C keyword that I have never used, so I know its
> name ;-)
>
> Let me repeat the code I presented for the Value system:
>
> struct Value {
> union {
> double real;
> int integer;
> ...
This somehow reminds me to the systems of "prope
On Mon, Mar 15, 1999 at 04:07:08PM +0100, Andre' Poenitz wrote:
> 1. LyX is *more* than a LaTeX frontend, so the excuse "LaTeX can't cope
>with it (natively), so we can't have it in LyX" might put off people
>who want do use LyX for HTML or maybe even just for displaying
>things on scr
On Fri, Mar 19, 1999 at 07:17:12PM +0100, Asger Alstrup Nielsen wrote:
> [Unions]
[Value Implementation]
> So, in the Paragraph structure, I propose that we simply have this:
>
> struct Paragraph {
>
> map settings;
> };
>
> So the "settings" map is our state of the paragraph.
>> Asger Alstrup Nielsen writes:
AAN> [Unions]
>> That is probably the only C keyword that I have never used, so I
>> know its
AAN> name ;-)
AAN> Let me repeat the code I presented for the Value system:
AAN> struct Value { union { double real; int integer; bool boolean;
AAN> str
[Unions]
> That is probably the only C keyword that I have never used, so I know its
name ;-)
Let me repeat the code I presented for the Value system:
struct Value {
union {
double real;
int integer;
bool boolean;
string str;
wstring wstr;
On Fri, Mar 19, 1999 at 06:22:10PM +0100, Jean-Marc Lasgouttes wrote:
> Jose> One thing that docbook uses are labels inside the the
> Jose> different tags. Is it possible to have reserve space to this in
> Jose> a sensible way?
>
> Hmm, labels as in LaTeX \label? Yes, it would be really nice
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
Jose> On Fri, Mar 19, 1999 at 06:10:15PM +0100, Jean-Marc Lasgouttes
Jose> wrote:
>> >From the top of my head we'll need at least two additional
>> variables: - a boolean indicating whether the heading is numbered
>> or not -
On Fri, Mar 19, 1999 at 06:10:15PM +0100, Jean-Marc Lasgouttes wrote:
> >From the top of my head we'll need at least two additional variables:
> - a boolean indicating whether the heading is numbered or not
> - a text inset containing the optional caption
One thing that docbook uses are labels
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> I'm inclined to think that having a specific Heading inset may be a
>> flaw. That kind of info should be pushed into a layout file so we
>> have more generic handling of documents.
Asger> Yes, you are right. We don't need a
> I'm inclined to think that having a specific Heading inset may be a flaw.
> That kind of info should be pushed into a layout file so we have more
> generic handling of documents.
Yes, you are right. We don't need a specific Heading object.
At the top level, we could only have "paragraph" obj
On Thu, 18 Mar 1999, Asger Alstrup Nielsen wrote:
> > Jose> If the external declaration says the no omiting tags are
> > Jose> allowed, then it is really needed. XML is a case where you have
> > Jose> to close all the tags, so the document is seen as a tree, the
> > Jose> DOM gives you a way t
> Sectioning and toc levels are defined there only in relation to the preceding
> one. Same level, one level down, one or several levels up. The advantage here
> is: You can cut and paste, move around add or remove levels up to a maximum
of
> 12. The interior logic of those parts will always remai
On Tue, 16 Mar 1999 13:30:39 +0100 (MET), Asger K. Alstrup Nielsen wrote:
>> > We will allow more nesting with a HeadingInset with a counter, than with
>> > position in a tree: We can only nest to the number of different
>> > pointers to Insets we have, and this is typically smaller than the ran
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> Two consecutive paragraphs in an InsetEnvironment would be in
Allan> the same environment (obviously). But I think what you mean
Allan> is: can this scheme allow two consecutive environments of the
Allan> same type?
What I meant is t
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> [How to get intelligent font changes. Allan suggests that we
Asger> map the font structure in the data representation in some way.]
Asger> I suggest that we ignore the issue in the data representation
Asger> part, and jus
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> My example was not support to provide an identifier for each inset,
>> but for each inset *class*. Just a way to avoid those enums. I'm
>> not sure it makes sense, however. That's just a way to allow insets
>> unknown to the ke
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Another example is the quote inset: it uses information from the
>> buffer (encoding, language) to determine the LaTeX output.
Asger> This is also solved the "painter way": When we ask an inset to
Asger> write some LaTeX, we p
> The current linear support relies upon recursion (at least in writing to
> files) and duplication of code to place the end markers and control
> output. If we move everything to Insets then the export routines are
> dependent upon Insets (either as member functions of the Inset or as
> multiple-
> Another example is the quote inset: it uses information from the
> buffer (encoding, language) to determine the LaTeX output.
This is also solved the "painter way": When we ask an inset to write some
LaTeX, we pass a Buffer pointer to it.
Alternatively, the Quote inset will be done a different
[How to get intelligent font changes. Allan suggests that we map the font
structure in the data representation in some way.]
I suggest that we ignore the issue in the data representation part, and just
record font changes in a linear fashion as already proposed.
Then, the problem is a problem o
> Jose> If the external declaration says the no omiting tags are
> Jose> allowed, then it is really needed. XML is a case where you have
> Jose> to close all the tags, so the document is seen as a tree, the
> Jose> DOM gives you a way to navigate the document as a tree like
> Jose> structure. S
> My example was not support to provide an identifier for each inset,
> but for each inset *class*. Just a way to avoid those enums. I'm not
> sure it makes sense, however. That's just a way to allow insets
> unknown to the kernel to register themselves.
The better way is just to use strings. Th
Hi,
I haven't copied Alan's last message but I totally support is view.
With such a scheme it would be very easy both to output docbook and xml
documents.
José
On Wed, 17 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>
> >> It seems to me that currently the include inset needs to know about
> >> its parent to work correctly. To make this change, we'd have to
> >> pass extra information in s
On Wed, 17 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> These aren't commands they are environments! They have start
> Allan> and end tags that must match. Therefore we need the
> Allan> InsetEnvironment to support multiple paragraph
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>> Jean-Marc Lasgouttes writes:
JL> - basically, a table cell contains *one* paragraph in LR mode.
Lars> I call that a line, not a paragraph.
Note that it can be several lines if you put linebreaks (\\) in there.
JL> If you fix t
> It seems to me that currently the include inset needs to know about
> its parent to work correctly. To make this change, we'd have to pass
> extra information in some cases.
Yes, this is needed, but this is a different situation:
We are talking about two different kinds of ownership:
1. Which
>> Asger K Alstrup Nielsen writes:
AKAN> Ok, I think we have settled this issue then: Headings are not
AKAN> nested in a tree. Instead, we will use counters to represent
AKAN> the nesting information.
So then we have that a buffer contains (on the first level in the
tree)
paragaphs objec
> Every inset with an associated popup needs to know which buffer it belongs
> to so the popup can talk to it (eg. get/set data). I haven't given much
> thought to removing this requirement but I am certainly open to
> suggestions.
Precisely, the Inset's need to know the BufferView where the
cli
>> Jean-Marc Lasgouttes writes:
JL> - basically, a table cell contains *one* paragraph in LR mode.
I call that a line, not a paragraph.
JL> If you fix the width of the cell, it will contain a list of
JL> paragraph (like in a parbox).
Not unless you also put a parbox inside the table cel
> > We will allow more nesting with a HeadingInset with a counter, than with
> > position in a tree: We can only nest to the number of different
> > pointers to Insets we have, and this is typically smaller than the range
> > of an integer.
>
> ??? I don't understand. A tree is defacto unlimite
> [How should we handle nested headings? Andr=E9 suggested that the level
> of headings should be represented by the position in the tree. I think
> it was a mistake that he only sent it this proposal to me personally, so
> here is my reply.]
Erm... yes..
> This is problematic if Paragraphs a
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
[Andre' said]
>> I think, we missed some crucial point:
>>
>> If all is nicely structured as a tree internally, we do not even
>> need different types (insets? ;-P) of headings: The type of a
>> heading is indicated by its positi
[How should we handle nested headings? André suggested that the level
of headings should be represented by the position in the tree. I think
it was a mistake that he only sent it this proposal to me personally, so
here is my reply.]
[Nesting is slower in performance.]
> This, of course, depents
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
Andre'> If these paragraphs have different properties, why not? Why
Andre'> not at all?
Andre'> I don't know whether you have worked with one of the newer
Andre'> releases of Maple or Mathematica. They both have a really nice
Andre'>
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
Jose> On Tue, Mar 16, 1999 at 11:36:15AM +0100, Jean-Marc Lasgouttes
Jose> wrote: [...]
>> José, does DocBook require some sort of tree form for sections? In
>> this case, we can probably provide an iterator that gives this vi
On Tue, Mar 16, 1999 at 11:36:15AM +0100, Jean-Marc Lasgouttes wrote:
[...]
> José, does DocBook require some sort of tree form for sections? In this
> case, we can probably provide an iterator that gives this view of a
> buffer.
If the external declaration says the no omiting tags are allowed
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> And why not a registering mechanism, where each inset registers
>> himself and gets an unique identifier? Each Inset could have a id
>> member that contains that. Something like the following (not
>> tested, and not really we
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Do you mean that a change of font would mean a change of inset?
Asger> Yes. This makes displaying of a InsetText simple, and we avoid
Asger> the ugly font-lists. I feel things are simpler this way.
Asger> (Notice that we c
On Tue, Mar 16, 1999 at 07:12:01PM +1000, Allan Rae wrote:
[...]
>
> InsetEnvironment and even an improved InsetCommand will build most of our
> documents hierarchy. Headings and such are ultimately one of these two
> types and a simple linear list of paragraphs doesn't allow for the needs
> of
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I have come to the conclusion that I prefer that we just store
Asger> this as a list of four paragraphs.
Asger> The trouble of nesting this structure into a tree is not worth
Asger> it: It decreases efficiency, because g
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>> Asger K Alstrup Nielsen writes:
AKAN> However, this does not resolve the issue of whether a paragraph
AKAN> should be an inset or not.
Lars> by using paragraph as an updatable inset, it can have full
Lars> control over mouse and
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On Tue, 16 Mar 1999, Asger K. Alstrup Nielsen wrote:
>> > Asger> Does an inset really need to know the owner of itself?
>> [buffer] > > It is needed in some cases.
>>
>> When?
Allan> Every inset with an associated popup needs to know
On Mon, 15 Mar 1999, Andre' Poenitz wrote:
> > We certainly do not want that. But it does not make sense to me in any
> > document to include a paragraph into a paragraph without some kind of
> > wrapper which specifies the semantics of the inner paragraph.
>
> If these paragraphs have different
On Tue, 16 Mar 1999, Asger K. Alstrup Nielsen wrote:
> > Asger> Does an inset really need to know the owner of itself? [buffer]
> >
> > It is needed in some cases.
>
> When?
Every inset with an associated popup needs to know which buffer it belongs
to so the popup can talk to it (eg. get/set d
>> Asger K Alstrup Nielsen writes:
AKAN> However, this does not resolve the issue of whether a
AKAN> paragraph should be an inset or not.
by using paragraph as an updatable inset, it can have full control
over mouse and keys.
but I also tend to agree with Jean-Marc. Can we combine the two
> but surely, a paragraph does not need to be an inset.
>
> paragraph in paragraph
>
> heading
> paragraph 1
>
> subheading
> paragraph 2
>
> How do we store this?
I have come to the conclusion that I prefer that we just
store this as a list of four paragraphs.
The trouble of nesting this st
> Asger> Does an inset really need to know the owner of itself? [buffer]
>
> It is needed in some cases.
When?
> Do you mean that a change of font would mean a change of inset?
Yes. This makes displaying of a InsetText simple, and we avoid
the ugly font-lists. I feel things are simpler this
[A character in Emacs is 22 bytes. Unicode insets are similar.]
> Arghh, do you mean we are heading to a emacs-weighted program?? I'd
> rather avoid that.
No. I'm just stating that a bunch of Unicode insets in your Latin1
encoded document will not severly affect performance.
If you need more Uni
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> paragraph in paragraph
Lars> heading paragraph 1
Lars> subheading paragraph 2
Lars> How do we store this?
Lars> One option is to let para 2 be inside para 1.
Yes, but it only makes sense becasue you have some context and k
On Mon, Mar 15, 1999 at 05:09:50PM +0100, Jean-Marc Lasgouttes wrote:
> > "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
>
> Jose> Docbook documents generaly have some metadocumentation in the
> Jose> paragraph, where you specify the title, the authorgroup, the
> Jose> dat
>> Jean-Marc Lasgouttes writes:
JL> But a paragraph itself is a list of insets (text or others). Why
JL> would it have to be an inset too?
It is much nicer to think of it as a inset, then we can move it around
just like any other inset. we will prob have different classes of
insets.
but su
> We certainly do not want that. But it does not make sense to me in any
> document to include a paragraph into a paragraph without some kind of
> wrapper which specifies the semantics of the inner paragraph.
If these paragraphs have different properties, why not?
Why not at all?
I don't know wh
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
Jose> Docbook documents generaly have some metadocumentation in the
Jose> paragraph, where you specify the title, the authorgroup, the
Jose> date, etc. The authorgroup is a new unit where the authors are
Jose> presented, eac
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>> Jean-Marc Lasgouttes writes:
JL> OK, I'll bite: give me *one* example of nesting a paragraph into
JL> another paragraph where you will not need some container around
JL> it, to make precise the type (footnote), the size (parbox)
On Mon, Mar 15, 1999 at 04:11:28PM +0100, Jean-Marc Lasgouttes wrote:
> Asger> It just holds a ParagraphInset?
> >> As I said earlier, I think it should hold either a plain box (in
> >> LR mode) or a parbox (with fixed width). It makes not sense to
> >> include a paragraph in a paragraph. And par
>> Jean-Marc Lasgouttes writes:
JL> OK, I'll bite: give me *one* example of nesting a paragraph into
JL> another paragraph where you will not need some container around
JL> it, to make precise the type (footnote), the size (parbox) or
JL> whatever.
I think a paragraph should be an inset
> "Andre'" == Andre' Poenitz <[EMAIL PROTECTED]> writes:
Asger> It just holds a ParagraphInset?
>> As I said earlier, I think it should hold either a plain box (in
>> LR mode) or a parbox (with fixed width). It makes not sense to
>> include a paragraph in a paragraph. And paragraphs should n
> Asger> It just holds a ParagraphInset?
>
> As I said earlier, I think it should hold either a plain box (in LR
> mode) or a parbox (with fixed width). It makes not sense to include a
> paragraph in a paragraph. And paragraphs should not be insets.
I actually see no point in handling paragraphs
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> The signal idea is meant for a very limited number of types and
Allan> is not supposed to be used for each and every inset type. I
Allan> can't see why everyone seems to think I'm advocating that all
Allan> inset types connect to a sp
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Aren't we trying to fix something that is not broken with a
Asger> complicated system of signals, slots, auto-pointers and other
Asger> advanced techniques?
I tend to agree that we should try to keep things simple.
Asger>
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> Why? Why would we want all Unicode insets to connect to a signal?
>> Why would we want all insets connecting to signals?
Asger> Aside: Even with many Unicode insets, this is not too bad. I
Asger> think Emacs uses around 22 b
On Sun, 14 Mar 1999, Asger Alstrup Nielsen wrote:
[how apply() + insets works]
> There is no bug, as far as I can see...
Ahhh I misread and didn't realise the loop was in document->apply()
iterating over the insets it contained. Silly me :)
> Of course, we need to abstract the apply-interf
> I'm still working on the automatic update upon insertion/removal from a
> buffer.
I hope you can solve the administration problems.
However, I'm still not convinced that this signal/slot thing is the best
solution. I'll explain in more detail below..
> Mind you, making the cutBuffer into
> > int widest_bib_item(Inset const * inset, int widest_so_far) {
> > if (inset->name == "Bib" && inset->width > widest_so_far)
> > return inset->width;
> > return widest_so_far;
> > }
> > and then do something like this on the document inset:
> >
> > int widest_bib_item = doc
On Sun, 14 Mar 1999, Asger Alstrup Nielsen wrote:
[...]
> Yes, this would not be as efficient as your scheme, because your scheme targets
> precisely the insets that are affected, while my idea is much worse, because we
> visit all insets.
> However, your scheme involves some administration of t
On Sun, 14 Mar 1999, Asger Alstrup Nielsen wrote:
>
> The idea was that by adding a method that would execute a function every inset,
> we could generalize many operations with one method.
>
> If the action is restricted to only some insets, the function that we apply
> should check for this its
> Why? Why would we want all Unicode insets to connect to a signal?
> Why would we want all insets connecting to signals?
Aside: Even with many Unicode insets, this is not too bad. I think Emacs uses
around
22 bytes for every single character in a document, so LyX should be able to
handle the
On Fri, 12 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> Thus for a 32-bit machine every signal or derived class adds
> Allan> 20bytes. Every connection that we then make adds another 28+4n
> Allan> bytes where n is the number of callb
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> Thus for a 32-bit machine every signal or derived class adds
Allan> 20bytes. Every connection that we then make adds another 28+4n
Allan> bytes where n is the number of callback data parameters. Since
Allan> we aren't using callbacks
On Mon, 8 Mar 1999, Asger Alstrup Nielsen wrote:
> > Example code for using signals to reduce the need for rtti or
> > inset codes. No need to identify insets, they identify themselves by
> > connecting to appropriate signals. This scheme means we don't have
> > to scan a buffer looking for pa
Sorry for the slow reply.
On Tue, 9 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> // Allan (ARRae) // Example code for using signals to reduce
> Allan> the need for rtti or // inset codes. No need to identify
> Allan> insets, they id
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> What about using a similar technique, but in a higher level
Asger> fashion? Instead of having customized signals for every little
Asger> thing, we will instead have a generic Variable-system, a
Asger> generic Function-syst
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> // Allan (ARRae) // Example code for using signals to reduce
Allan> the need for rtti or // inset codes. No need to identify
Allan> insets, they identify themselves by // connecting to
Allan> appropriate signals. This scheme means we
> Example code for using signals to reduce the need for rtti or
> inset codes. No need to identify insets, they identify themselves by
> connecting to appropriate signals. This scheme means we don't have
> to scan a buffer looking for particular inset types.
>
> NOTE: this doesn't solve all pr
82 matches
Mail list logo
