On Fri, Oct 05, 2007 at 02:49:47AM +0200, Dov Feldstern wrote: > > > 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).
Easy (?), but not very user friendly. Should I really look all the time into the status bar? And no, underlines don't really work here either. Not as well as the real frame of a real inset ;-) > >>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. True. For this case user-definable range attributes are the solution. Somebody else may implement these though, and he has a significant clean-up job on his hands first. It's certainly doable: I did it -- minus user definability etc. -- for the char range branches prototype. I still would not base charstyles for the general user base on this, based on the reasons I presented. Having inset-based charstyles doesn't preclude the later implementation of "semantic ranges" (or what would you call it) by someone having a professional interest in this. > 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. It does... you can split one of the insets. Semantically wrong -- but then, so would be the use of multiple hard-spaces. > >>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. > > Hmmm, in a way yes. > 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. > >>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 LyX wouldn't be LyX if this argument were applied more generally ;-) ...and for LyX users, familiarity with many other inset types argues similarly for inset-type charstyles. > >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. Yes, 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. > >4) all cursor movement is based upon what I can see Also true for the inset alternative if inset boundaries are visible. > 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. This is in fact the only valid objection (to the current charstyle implementation) that I recognise: it looks ugly and is visually disruptive -- for charstyles containing more than a few words. > >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 - Martin
