Martin Vermeer wrote:
I gained some new understandings from this discussion. If
others did too and act on it, it will make a difference:
Yes, me too. And these observations are good (though I don't necessarily
agree with all of them ;) ), and I will keep them in mind as we
hopefully proceed to implement Ranges, to augment the charstyle insets.
- The difference between pre-existing and user-creatable
semantics, special status of emphasis (Dov)
- But 'Noun' is more natural as an inset charstyle
- A 'strong' style similar to 'emph' in range mode is needed
- Jurgen's idea: a combobox for inset charstyles, including
a remove/none item, probably based on dissolve
- What to do with 'code'? More thinking needed. We have LyXCode
- What about the ambiguity in the Emph toggle? Do we mean
to make a non-emph hole, or an emph-within-emph? And does
the latter require an inset-emph after all?
Those are my thoughts on this.
- Martin
I still contend that by insisting on charstyles-as-insets, two separate
issues are being confused, namely (1) placing the "semantic entity" in
an inset, and (2) giving the entire entity a charstyle. However, I can
live with this for now. And, I'm not so sure anymore that we should
stick with character attributes implementation long-term; the CharStyle
mini-layouts seem quite nice :) . Perhaps *that* could be used as the
single underlying font attributes implementation...
So here's my suggestion for how to continue with this (this is similar
to what I presented a few days ago, with a few modifications):
My ultimate goal would be to have three kinds of objects:
(1) Insets: the purpose of an inset is to show that the contents
should be treated as a single unit, in some semantic sense, relative to
the containing paragraph. InsetFlex (perhaps with some minor
modifications once Ranges also exist) serves this purpose well, I think.
Basically, I want this inset to mainly provide an inset UI, and not much
else.
(2) Ranges: the idea of a range is to delimit some part of a larger,
already existing text for some purpose.
(3) CharStyles: a CharStyle defines the font attributes of a specific
chunk of text.
The user should be able to either select existing text and "wrap" it in
either an Inset or a Range; or create a new Inset or Range, into which
new text will be placed. In either case, the user will be able to
"attach" a CharStyle to the Range or Inset.
(The current charstyles-as-insets implementation is more or less what I
foresee as the "attaching charstyles to insets" part; so what's left is
to add a Ranges implementation, so that Ranges and Insets can be
more-or-less equal class citizens, and then attach charstyles to ranges
in a similar fashion.)
Another long-term goal is for there to be *only one* underlying
implementation of character styles (as opposed to the two we're going to
be having now: Insets and character attributes); and I'm starting to
think that perhaps a good way to do this would be by using the
"mini-layout CharStyles" attached to ranges (question for the inset
people: if a charstyle-inset were to be defined such that its entire
contents is contained within a range to which the given CharStyle is
attached, would that be OK? Again, just so that we can have only a
single underlying implementation of charstyles.)
So how do we reach this goal?
I think that any way we look at it, the first thing we (I guess that
means "the ranges people", I hope it doesn't mean just "me") have to do
is to provide a solid implementation of ranges. Until we have a good,
working Range implementation, there's not much that we can do.
Integral parts of the Range implementation should be Andre's suggestion
for how to store the ranges in the .lyx file; and the algorithm I
presented earlier --- together with JMarc's additions --- for
translating the character-based Ranges into legally nested entities for
latex (and this could even cope with non-nested ranges, though perhaps
not with complete success; I think we should view this possibility as a
"nice-to-have").
Once we do have such an implementation, I think it should not be too
hard to attach CharStyles to them (using the mini-layouts currently
being used for the charstyle insets). And the finally, we can shift all
of the current character attributes implementation to use the Range
mechanism (today they already use the font span, which is sort of a range).
Short term, the compromise suggested sounds reasonable (again, since I
see no real alternative until we have a working Range implementation).
Dov
