John Levon wrote:
On Thu, Oct 04, 2007 at 09:28:25PM +0300, Martin Vermeer wrote:
Just to complement John's list of advantages for ranges, I'd also like
to explain why I think the items on Martin's list do not preclude the
use of ranges:
Could you list the advantages of an exposed inset UI?
1) You know precisely where a typed character goes -- or where an
already typed character belongs. Inside or outside any given inset.
A special case of this is for blanks, which don't display much in
terms of rendering style.
This should be easy to solve for ranges as well. See, e.g., my thoughts
on this here http://permalink.gmane.org/gmane.editors.lyx.devel/96316.
In addition, we could also mark ranges using underlines, such as that
which marks foreign languages (which in its current implementation is
nothing but a character attribute).
2) The discipline of nesting is imposed corresponding to the logic of
semantics. Meaning, in the semantic sense, typically forms a tree.
Exceptions to that which I have seen are either more or less
pathological, or esoteric.
I don't see this is an advantage.
Not allowing certain behavior (e.g., multiple adjacent spaces) is
advantageous if almost always, that behavior is accidental (as is the
case with multiple spaces, at least once the user learns about the
"correct" way to do what he probably wanted to do with multiple spaces).
However, in our case, I don't think that users will often create
non-nesting character styles "by accident" (except maybe with spaces at
the boundaries).
Secondly (to continue with multiple spaces as an example of behavior
that we *do* choose to disallow), for almost any use-case of
multiple-spaces that I can think of, LyX provides a *better* solution
than multiple spaces, and I don't think that anyone would claim
otherwise. It may take a user some time to learn about these, but I
doubt that there are many users who learn about these, and still decide
that they want multiple spaces. In our case, however, if someone wants
non-nested markup (for one of the admittedly esoteric --- but
nonetheless valid --- reasons that we've mentioned, e.g., textual /
linguistic analysis), LyX with charstyles-as-insets would not provide
any alternative.
Thirdly, if our stubborn user *still* wants to have multiple spaces,
there is a very simple solution which LyX provides, in the form of
protected spaces. Again, no such solution exists for non-nested
character styles.
3) No ambiguity about nesting order.
I'm confused about the difference between 2 and 3. They sound like the
same thing: an inset UI enforces, clearly, a hierarchical style tree.
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.
4) Because of 2) and 3), no problems with our favourite back-ends, LaTeX
and XML.
Nor with ranges, using the disambiguation algorithm just mentioned.
I presume you're referring the specific case of getting certain style
"ligatures" wrong when you have to decompose a non-hierarchical style
system into a hier one, right? Otherwise it sounds like you're talking
about implementation.
Here are the user interface advantages I have for a ranges UI:
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
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
4) all cursor movement is based upon what I can see
Also, no need for playing around with the cursor movement code in order
to accommodate charstyles --- the existing code already works.
5) Line-wrapping looks and behaves naturally.
Note that I'm not listing overlapping styles. I don't think that's an
interesting use case.
Though again, if we can deal with it, too, I think that's a nice bonus
of ranges.
regards
john
Dov
