On Thu, Oct 04, 2007 at 09:17:32PM +0100, José Matos wrote:
> On Thursday 04 October 2007 21:05:58 Andre Poenitz wrote:
> > Well... then what about
> >
> > emph...strong..
> > emph.strong...
> >
> > This is 1:1 translatable to the structure above _and_ is more robust
> >
Andre Poenitz wrote:
On Thu, Oct 04, 2007 at 09:55:58PM +0200, Dov Feldstern wrote:
[...]
Rather we'd need to store that as something like
...
...
emph
...
...
strong
Hmm, yes, this does describe the structure that I'm thi
On Thursday 04 October 2007 21:05:58 Andre Poenitz wrote:
> Well... then what about
>
>
> emph...strong..
> emph.strong...
>
>
> This is 1:1 translatable to the structure above _and_ is more robust under
> manual editing.
I find your exchange highly amusing because some
On Thu, Oct 04, 2007 at 09:55:58PM +0200, Dov Feldstern wrote:
> > [...]
> >Rather we'd need to store that as something like
> >
> >
> >
> >
> > ...
> > ...
> > emph
> >
> >
> > ...
> > ...
> > strong
> >
> >
> >
>
> Hmm, yes, t
Andre Poenitz wrote:
On Wed, Oct 03, 2007 at 02:10:09PM +0200, Jean-Marc Lasgouttes wrote:
We define an "attribute precedence" order. Then, we use the following
rules (to be applied when moving from the GUI to non-overlapping
markup) to make sure that at any given position, the
highest-precedenc
On Wed, Oct 03, 2007 at 02:10:09PM +0200, Jean-Marc Lasgouttes wrote:
> > We define an "attribute precedence" order. Then, we use the following
> > rules (to be applied when moving from the GUI to non-overlapping
> > markup) to make sure that at any given position, the
> > highest-precedence active
Jean-Marc Lasgouttes wrote:
Dov Feldstern writes:
The truth is, if this information is available, then I would just
incorporate it into the precedence tables I suggest: so you'd have
dynamic precedence tables, which are ordered first by range extent,
and only when that's not enough (same range
Dov Feldstern <[EMAIL PROTECTED]> writes:
> The truth is, if this information is available, then I would just
> incorporate it into the precedence tables I suggest: so you'd have
> dynamic precedence tables, which are ordered first by range extent,
> and only when that's not enough (same range / o
Jean-Marc Lasgouttes wrote:
Dov Feldstern writes:
The trivial way to do this is just to say: well, whichever range
starts first I consider to be the outer range; and when I reach it's
end, I must also close all inner ranges, as well. If some of those
inner ranges are still open, then I will op
Dov Feldstern <[EMAIL PROTECTED]> writes:
> The trivial way to do this is just to say: well, whichever range
> starts first I consider to be the outer range; and when I reach it's
> end, I must also close all inner ranges, as well. If some of those
> inner ranges are still open, then I will open t
Here's an outline for how we could deal with overlapping ranges, using
character attributes.
First, we must understand what exactly the problem is: it is currently
perfectly possible (and should remain so) to have in the GUI markup
which would looks like this:
abc def ghi
However, this is i
11 matches
Mail list logo
