On Fri, Oct 05, 2007 at 06:37:05AM +0300, Martin Vermeer wrote:
> > If what Martin means is that *LyX* will have no ambiguity, e.g, when
> > generating latex/XML, then I think that the disambiguation algorithm
> > suggested in this thread
> > http://permalink.gmane.org/gmane.editors.lyx.devel/95997 (plus the
> > refinement suggested by JMarc, which uses the extent of the ranges, see
> > the whole thread) would solve any ambiguities that might arise with
> > ranges; hence, this is not an advantage relative to ranges.
>
> Doesn't exist yet, and doesn't sound simple.
It's also pretty self-contained. Sometimes we must take the hit of some
slightly more complicated code for a better UI experience.
> > >1) familiarity. This is how every other editor I'm familiar with works.
> > >In particular problems like "what happens if I have some text with style
> > >selected, and choose another style" can be solved in the same fashion as
> > >other programs, when it makes sense
>
> LyX wouldn't be LyX if this argument were applied more generally ;-)
That's absolutely true. However, *unless we have good reason to* we
should not diverge from what people are used to.
> ...and for LyX users, familiarity with many other inset types argues
> similarly for inset-type charstyles.
I think this is the fundamental problem the inset people have: they
think that the way people use mathed and insets now is somehow like the
way they mark up blocks of text. It's simply not true.
There are two cases you could claim here. First, we have footnotes,
branches and the like. These contain normal text so seem superficially
similar. However, even the footnotes-crazy social science people don't
use insets as much as normal people would mark up text. More importantly
though, navigation *through* such items is significantly less common (if
this weren't true, then being able to collapse them wouldn't be so
useful). It's quite different from the contents of a "normal" flow of
text.
Secondly, we have mathed. Equations are highly structured and require
precise control in a way that normal text doesn't. You never need to
type stuff like:
c/d or b
b c/d
a a
with normal text; more importantly, you never need to navigate such a
structure. It's a completely different way of navigating and
constructing output.
There is no such familiarity.
> > >2) The existence of a style attribute does not affect how and where I
> > >can select text
> > >
> > >3) Selection never 'jumps' - it always starts at the point I started,
> > >and ends at the nearest character to the position of the pointer
>
> 2) and 3) are aspects of the same thing, and IMHO an inevitable
> consequence of hierarchy.
They're an inevitable consequence of the way *you* enforce hierarchy.
> you could modify selection so you can have contiguous parts of
> different insets/main text -- but you could never apply a new style
> around that selection. Better leave it as it is.
Um, absolutely not true of ranges. This will work fine. Try any other
program out there.
> > >4) all cursor movement is based upon what I can see
>
> Also true for the inset alternative if inset boundaries are visible.
Which would make normal text pretty unreadable (much like it is now).
regards,
john
