>>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Thu, Sep 19, 2002 at 02:38:23PM +0200, Jean-Marc Lasgouttes
Andre> wrote: No, it is not....
>> It is very convenient to use 99% of the times. It just works.
Andre> It does not work and it can't be worked around.
What does not work? [besides the already mentionned problem?]
Asfor why I find it convenient, I do not like to use gratuitously the
mouse or the cursor key to change the depth of something (think about
a nested enumeration, and how you might not be sure how to organize
it; would you rather use depth-increment or <click><cut><click><paste>?)
Andre> [Btw: Have you noted that you are accusing me of being ignorant
Andre> to certain kinds of usage patterns (and rightly so btw) but do
Andre> exactly the same with patterns that do not fit into your
Andre> model?]
Of course. What did you believe? We are both defending our usage
patterns and trying to negociate to find a middle ground. However, the
difference is that I do not want to make the decision on the number of
lines of code that we would gain. The examples you gave (minipage,
footnote, table, ert) are actually examples where the UI has been
improved or kept unchanged. The user should not have to suffer from
any code simplification (though he did with 1.2.0). Code is irrelevant
to this discussion.
Andre> It is not possible to have "sub-paragraph layouts" as I would
Andre> think are needed for "character styles" and it is not possible
Andre> to have "multi-paragraph" styles (like \begin{comment}...) - oh
Andre> wait, nowadays we don't use comment, we rather use a note.
Andre> Which - surprisingly - is an inset.
Comment was crap anyway. A more interesting version of this problems
is things like the 'Slides' environment. I admit I do not have a good
solution to this problem right now (except for the container inset I
outlined in another post, but I know this would not be practical).
Andre> Well, I would not mind if this were implemented
Fine
Andre> - even if this means extra code which is completely unnecessary
Andre> in the inset approach
Remember, this is irrelevant :)
Andre> (where you either have an inset with two paragraphs or two
Andre> insets - again something were order _is_ important...)
Sorry, I do not understand what you mean here.
>> Whereas with the structured approach, you get almost everything
>> annoying to do,
Andre> Like what? What is annoying with the inset approach which works
Andre> better on the flat model?
Using more cursor keys for the dubious benefit of precise font
placement (this is for fonts) or replacing the depth machanism with
insertion and deletion of bix boxes (this is for layouts)
Andre> LFUN_LAYOUT (or similar) could be used to switch the style of
Andre> the inset enclosing the cursor. Or an new LFUN_MUTATE if you
Andre> want. Guess what mathed does when going from inline do display
Andre> to eqnarray etc...
And then you will have to make it completely driven from the layout
style (nothing hardcoded, not like the 55 different insets known to
mathed). This means that an enumerate inset should be the same object
somehow that an itemize item (since we want to control that from
textclass). And this means that you will need to still use a lot of
the code that is currently in LyXText or Paragraph.
JMarc
