Andre Poenitz wrote:
On Wed, Aug 15, 2007 at 02:33:16AM +0300, Dov Feldstern wrote:
Mael Hilléreau wrote:
Le 15 août 07 à 00:32, Andre Poenitz a écrit :
On Wed, Aug 15, 2007 at 12:16:47AM +0300, Dov Feldstern wrote:
[..] The problem is, this is not working --- even now with
branches, as I just found out thanks to your question --- in
certain cases which involve Bidi text (and maybe other kinds of
transitions). In other words, in these situations, for "abc def
ghi" I get one output, and for "abc [def] ghi" (in which the branch
is activated, of course) I get *different* output. So I'm not
saying that we should now go and implement branches as character
attributes rather than insets (though that may actually not be a
bad idea...;) ); but if we're doing this again in another
situation, I say we keep it simple this time.
Have you actually pondered the consequences of an 'all is an inset'
approach? [Serious question, including the ability of the
'three-box-drawing'
.-----------------.
| |
.----' |
. |
. .---'
`------------------'
This kind of display wouldn't be possible with a char-level approach,
indeed.
I don't understand --- not Andre's question, nor Mael's response... :(
There are several ideas or concepts related to LyX that have been around
for a long time and pop up every now and then, either because similar
ideas are rediscovered on lyx-devel or somebody feels the original idea
should be reevaluated as the infrastructure might have changed in a way
that the original reasoning does not apply anymore.
One of the ideas is 'everything is an inset'. 'Everything' in the most
radical version would be what we call nowadays 'inset', 'paragraphs',
'charstyle', and 'font change'.
It is a pretty clear concept, but it would need some work for drawing
since we obviously can't display fontchanged and also charstyles in a
single rectangular box. Solution would be the three-box-model. Then
the document structure changes in a way that's pretty incompatible with
the current .lyx format. Now as this is about to change this might be
much less of an obstacle after 1.6 is out. Thirdly, it is not clear how
cursor navigation is to be implemented in this case to make it 'feel
right' (or at least 'not obviuosly wrong'). As mathed more or less
already follow the 'everything is an inset' concept, we do have a
testing playground, be we also see that even given a few years to mature
the result is not perfect. And maybe there is no perfect solution...
Andre'
Thanks for the explanation, Andre'.
The only thing I have to add to this, is that I think the "everything is
an inset" approach will also be problematic in terms of the
latex-output. Currently, the latex generation is too-closely tied with
the representation of the document within LyX itself. I can't exactly
pinpoint what the problem is; but one example is that there are certain
latex commands (e.g., language or font switches) which can't accept
paragraph breaks within them; and therefore, we close these when we
arrive at an inset, because the inset may contain paragraph breaks. But
that means that the presence of an inset will inherently cause a change
in the latex output, even if it needn't really change it in any way.
Especially in a BiDi context, this kind of thing can have consequences
for the final output, too.
I posted my not-very-clear thoughts on this issue about a month ago,
here: http://permalink.gmane.org/gmane.editors.lyx.devel/90237.
So all I'm saying is, I think that the "everything is an inset" approach
will aggravate these problems a lot, if we don't first solve the
latex-generation issue (which will not be easy...).
Good night!
Dov
