Jean-Marc Lasgouttes wrote:
>>>>>> "Alfredo" == Alfredo Braunstein
>>>>>> <[EMAIL PROTECTED]> writes:
>
> Alfredo> Darren Freeman wrote:
>>> According to the View->Source panel, these both result in $Ge^{3}$.
>>>
>>> Did this get broken recently? I have been using this "feature" to
>>> put my chemical elements as the nucleus of a subscript for a while
>>> and I'd hate to think it was for nothing.
>>>
>>> Also, shouldn't LyX refrain from outputting the curly braces on the
>>> sub/superscript unless it's more than one char?
>
> Alfredo> From a quick research with svn I've found two seemingly
> Alfredo> relevant (not sure really) entries. Seems we don't output
> Alfredo> them because it's a problem reading them back?
To which braces do you refer? The one of the sub/superscript are AFAIK
always output. It would probably be possible to leave them out, but why?
The ones around a multiple character nucleus need to be added manually (by
a brace inset). Reading braces back is in no case a problem.
> Maybe JMarc or
> Alfredo> Georg know what's happening?
>
> Yes, I tried to 'optimize' this stuff last summer, and the result was
> that I introduced several strange bugs (in particular one that only
> happened in windows (and for which no reason as been found AFAICR)).
>
> This is very fragile stuff.
That depends. It is fragile if you try to be clever during parsing and
remove insets that have been created previously, and add them back in
write() again. As long as you do normal parsing without removing insets it
is quite robust.
Currently everything is working perfectly. There is only one drawback
concerning the representation on screen: For things like {ab}^{c} the
braces around {ab} are shown in red, and if you want to enter such things
you need to enter a brace inset around ab. This is what Jean-Marc wanted to
optimize, but we came to the conclusion that it is not possible to do this
in a way that would always work.
Georg
