On Sun, Oct 07, 2007 at 08:31:06PM +0100, John Levon wrote: > On Sun, Oct 07, 2007 at 10:13:54PM +0300, Martin Vermeer wrote: > > > > sense for the UI to express this semantic difference. How does this > > > advantage the user? I don't remember seeing a clear answer to this > > > question. > > > > Isn't 'natural' usually better? These things feel like atoms, > > and inset-ness supports that. Not a big thing but anyway. > > I don't believe that people will think it's natural that selection jumps > across an entire (say) <firstname>.
If they feel that way, it is because they have been prejudiced by other applications... it _is_ natural. Rarely if ever will you want to select a piece of a <firstname> together with an adjoining piece of <surname>, e.g. Just doesn't happen. > > Ability yes. Resources... at the expense of what? Inset-based > > charstyles work here and now. > > Indeed, perfect is the enemy of the good. Most likely all this > discussion will make no difference. But at least we tried. I gained some new understandings from this discussion. If others did too and act on it, it will make a difference: - 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
