Re: super/subscript insets
* Andre Poenitz [EMAIL PROTECTED] [010711 17:33]: Dekel Or \limits after \sin \sin is a \mathop, right? Dekel And note that currently a subscript after \underbrace is Dekel rendered incorrectly. In fact, \underbrace is a \mathop too. Mathed should know about which insets/entities are mathops. Does this mean we basically have two things: - ordinary scriptinsets that appear after say 'a' or nothing that don't have \limit/\nolimit - mathops (\sum, \sin, \underbrace...) that can have su*scripts that could have \limit etc... ? One addition though, we'll need some method to easily add such operators, for example in Real Analysis there is a need for an ess-sup operator that is not usually defined, this operator effectively should be rendered like sup or lim with the limit under in. I'm pretty sure that there are more of this things in various branches of mathematics so it should be possible to add to it on runtime/startup. -- Baruch Even http://baruch.ev-en.org/
Re: super/subscript insets
Baruch == Baruch Even [EMAIL PROTECTED] writes:
Baruch One addition though, we'll need some method to easily add such
Baruch operators, for example in Real Analysis there is a need for an
Baruch ess-sup operator that is not usually defined, this operator
Baruch effectively should be rendered like sup or lim with the limit
Baruch under in.
Baruch I'm pretty sure that there are more of this things in various
Baruch branches of mathematics so it should be possible to add to it
Baruch on runtime/startup.
This would just mean implementing \mathop{}, AFAIK. And then many math
operators could be defined as (internal) user-defined macros. Of
course this would be practical only if macro edition is changed to add
the extra boxes only when needed (when a parameter is used more than
once).
JMarc
Re: super/subscript insets
* Andre Poenitz <[EMAIL PROTECTED]> [010711 17:33]: > > Dekel> Or \limits after \sin > > > > \sin is a \mathop, right? > > > > Dekel> And note that currently a subscript after \underbrace is > > Dekel> rendered incorrectly. > > > > In fact, \underbrace is a \mathop too. Mathed should know about which > > insets/entities are mathops. > > Does this mean we basically have two things: > > - "ordinary" scriptinsets that appear after say 'a' or nothing > that don't have \limit/\nolimit > > - mathops (\sum, \sin, \underbrace...) that can have su*scripts > that could have \limit etc... > > ? One addition though, we'll need some method to easily add such operators, for example in Real Analysis there is a need for an ess-sup operator that is not usually defined, this operator effectively should be rendered like sup or lim with the limit under in. I'm pretty sure that there are more of this things in various branches of mathematics so it should be possible to add to it on runtime/startup. -- Baruch Even http://baruch.ev-en.org/
Re: super/subscript insets
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch> One addition though, we'll need some method to easily add such
Baruch> operators, for example in Real Analysis there is a need for an
Baruch> ess-sup operator that is not usually defined, this operator
Baruch> effectively should be rendered like sup or lim with the limit
Baruch> under in.
Baruch> I'm pretty sure that there are more of this things in various
Baruch> branches of mathematics so it should be possible to add to it
Baruch> on runtime/startup.
This would just mean implementing \mathop{}, AFAIK. And then many math
operators could be defined as (internal) user-defined macros. Of
course this would be practical only if macro edition is changed to add
the extra boxes only when needed (when a parameter is used more than
once).
JMarc
Re: super/subscript insets
cursor position -- hard to explain/draw cursor-at-the-left-of-base vs. cursor-to-the-left-of-whole-inset. I am thinking about a special box around current inset - something not too visible - maybe with 'linen' colour. So one gets a hint where the cursor really is. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre Poenitz wrote:
cursor position -- hard to explain/draw cursor-at-the-left-of-base vs.
.
I am thinking about a special box around current inset - something not
too visible - maybe with 'linen' colour. So one gets a hint where the
cursor really is.
Interesting.
For $foo{X_{s}}bar$, that would mean:
* cursor to the left of X_{s} - whole formula highlighted
* cursor to the left of X - just X highlighted
There's no case where X_{s} gets highlighed, so there's no indication
that it's treated as a unit. But you *could* play loose and not adhere
precisely to the inset structure: things would look OK if you highlight
X_{s} instead of just X in the second case. Doesn't solve the extra
cursor movement problem, though.
Pracital problem: can't rely on fine color distinctions, some people
have bad screens (laptops) or run in 256 color modes. On the other hand,
the highlight of the whole formula turns off and on when you enter an
inset, so a strong color difference may be nauseating. Can draw a frame
instead, or something of the sorts.
About semantics, BTW, what's wrong with the current (and TeX's) implicit
the base is the first thing to the left? While the representation is
not explicit, the semantics are well-defined and easy to retrieve and
that's the important part.
Regards,
Eran Tromer
Re: super/subscript insets
Ok, I am convinced now.
Could you accept the following:
- There is a sub/superscript inset.
- The \limit/\nolimit information is part of this inset.
- When written to LaTeX, it will simply output _{...}^{...}.
- When displayed on screen, it will look one char/inset back and use that
information to draw itself.
This is some kind of exception, but I think it is a special case anyway.
TeX uses extra catcodes for ^ and _ and people are used to a certain way to
move around those beasts. I don't think implementation will get dirtier
than it is, on the contrary, e.g. the bigop inset will become much smaller
now.
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Ok, I am convinced now. Could you accept the following:
Andre - There is a sub/superscript inset.
Andre - The \limit/\nolimit information is part of this inset.
Note that this information only makes sense for some kind of elements
(\mathop) before the *scripts.
Andre - When written to LaTeX, it will simply output _{...}^{...}.
Andre - When displayed on screen, it will look one char/inset back
Andre and use that information to draw itself.
Go for it.
JMarc
Re: super/subscript insets
Andre - The \limit/\nolimit information is part of this inset. Note that this information only makes sense for some kind of elements (\mathop) before the *scripts. \underbrace seems to be another canditate... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre Poenitz wrote:
Could you accept the following:
Sounds good (the parts I grok, at least).
One gotcha:
LaTeX will choke on double scripts such as A_{s}_{t}, so we can't have
two script insets in sequence. But then, what happens if you have
A_{s}B_{t}? and delete the B (e.g., in order to replace it by C)? The
intermediate state would be the illegal A_{s}_{t}, but we must allow
it somehow. Possibilities:
* Allow the sequential script insets and display them similarly to
A_{s\,t}. Provide an informative error when exporting. This is the case
now, except the error is LaTeX's.
* Keep silent, export as A_{s}{}_{t}. Problem: will be created
unintentionally and go unnoticed.
* In this special case, show an empty (blue) cell in front of the _{t},
and export as A_{s}{}_{t} (empty cell = {}).
I think the last one would be best despite the unusual behavior.
Related issue:
In the situation (cursor = |)
A_{s}|
pressing '_' should take you to
A_{s|}
rather than 1.2.0cvs's
A_{|s}
or 1.1.6fix2's
A_{s}_{|}
But, in the situation
A|_{s}
pressing '_' should do the same as down and take you to
A_{|s}
like 1.2.0cvs does.
Regards,
Eran Tromer
Re: super/subscript insets
On Wed, Jul 11, 2001 at 02:47:51PM +0200, Andre Poenitz wrote: Andre - The \limit/\nolimit information is part of this inset. Note that this information only makes sense for some kind of elements (\mathop) before the *scripts. \underbrace seems to be another canditate... Or \limits after \sin And note that currently a subscript after \underbrace is rendered incorrectly.
Re: super/subscript insets
And note that currently a subscript after \underbrace is rendered incorrectly. I know. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
LaTeX will choke on double scripts such as A_{s}_{t}, so we can't have
two script insets in sequence. But then, what happens if you have
A_{s}B_{t}? and delete the B (e.g., in order to replace it by C)? The
intermediate state would be the illegal A_{s}_{t}, but we must allow
it somehow. Possibilities:
* Allow the sequential script insets and display them similarly to
A_{s\,t}. Provide an informative error when exporting. This is the case
now, except the error is LaTeX's.
* Keep silent, export as A_{s}{}_{t}. Problem: will be created
unintentionally and go unnoticed.
* In this special case, show an empty (blue) cell in front of the _{t},
and export as A_{s}{}_{t} (empty cell = {}).
Or make the base part of the inset ;-}
I just noticed that having the base _not_ part of an inset has another
disadvanage: in \sum_{} the subscript effectively determines
the width of the whole thing _and_ the position of the \sum char.
So rendering is no linear process anymore...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Dekel Or \limits after \sin \sin is a \mathop, right? Dekel And note that currently a subscript after \underbrace is Dekel rendered incorrectly. In fact, \underbrace is a \mathop too. Mathed should know about which insets/entities are mathops. Does this mean we basically have two things: - ordinary scriptinsets that appear after say 'a' or nothing that don't have \limit/\nolimit - mathops (\sum, \sin, \underbrace...) that can have su*scripts that could have \limit etc... ? If so, it would sound reasonable two implement thes two classes as seperate insets (that may share some code, but...) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Does this mean we basically have two things: Andre - ordinary scriptinsets that appear after say 'a' or nothing Andre that don't have \limit/\nolimit Andre - mathops (\sum, \sin, \underbrace...) that can have su*scripts Andre that could have \limit etc... Andre ? Andre If so, it would sound reasonable two implement thes two classes Andre as seperate insets (that may share some code, but...) Yes, that may be a good idea. JMarc
Re: super/subscript insets
> cursor position -- hard to explain/draw cursor-at-the-left-of-base vs. >cursor-to-the-left-of-whole-inset. I am thinking about a special box around "current inset" - something not too visible - maybe with 'linen' colour. So one gets a hint where the cursor really is. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre Poenitz wrote:
>
> > cursor position -- hard to explain/draw cursor-at-the-left-of-base vs.
> >.
>
> I am thinking about a special box around "current inset" - something not
> too visible - maybe with 'linen' colour. So one gets a hint where the
> cursor really is.
Interesting.
For "$foo{X_{s}}bar$", that would mean:
* cursor to the left of "X_{s}" -> whole formula highlighted
* cursor to the left of "X" -> just "X" highlighted
There's no case where "X_{s}" gets highlighed, so there's no indication
that it's treated as a unit. But you *could* play loose and not adhere
precisely to the inset structure: things would look OK if you highlight
"X_{s}" instead of just "X" in the second case. Doesn't solve the extra
cursor movement problem, though.
Pracital problem: can't rely on fine color distinctions, some people
have bad screens (laptops) or run in 256 color modes. On the other hand,
the highlight of the whole formula turns off and on when you enter an
inset, so a strong color difference may be nauseating. Can draw a frame
instead, or something of the sorts.
About semantics, BTW, what's wrong with the current (and TeX's) implicit
"the base is the first thing to the left"? While the representation is
not explicit, the semantics are well-defined and easy to retrieve and
that's the important part.
Regards,
Eran Tromer
Re: super/subscript insets
Ok, I am convinced now.
Could you accept the following:
- There is a sub/superscript inset.
- The \limit/\nolimit information is part of this inset.
- When written to LaTeX, it will simply output _{...}^{...}.
- When displayed on screen, it will look one char/inset back and use that
information to draw itself.
This is some kind of exception, but I think it is a special case anyway.
TeX uses extra catcodes for ^ and _ and people are used to a certain way to
move around those beasts. I don't think implementation will get dirtier
than it is, on the contrary, e.g. the bigop inset will become much smaller
now.
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Ok, I am convinced now. Could you accept the following:
Andre> - There is a sub/superscript inset.
Andre> - The \limit/\nolimit information is part of this inset.
Note that this information only makes sense for some kind of elements
(\mathop) before the *scripts.
Andre> - When written to LaTeX, it will simply output _{...}^{...}.
Andre> - When displayed on screen, it will look one char/inset back
Andre> and use that information to draw itself.
Go for it.
JMarc
Re: super/subscript insets
> Andre> - The \limit/\nolimit information is part of this inset. > > Note that this information only makes sense for some kind of elements > (\mathop) before the *scripts. \underbrace seems to be another canditate... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre Poenitz wrote:
> Could you accept the following:
Sounds good (the parts I grok, at least).
One gotcha:
LaTeX will choke on double scripts such as "A_{s}_{t}", so we can't have
two script insets in sequence. But then, what happens if you have
"A_{s}B_{t}"? and delete the B (e.g., in order to replace it by C)? The
intermediate state would be the illegal "A_{s}_{t}", but we must allow
it somehow. Possibilities:
* Allow the sequential script insets and display them similarly to
A_{s\,t}. Provide an informative error when exporting. This is the case
now, except the error is LaTeX's.
* Keep silent, export as "A_{s}{}_{t}". Problem: will be created
unintentionally and go unnoticed.
* In this special case, show an empty (blue) cell in front of the _{t},
and export as "A_{s}{}_{t}" (empty cell = "{}").
I think the last one would be best despite the unusual behavior.
Related issue:
In the situation (cursor = |)
A_{s}|
pressing '_' should take you to
A_{s|}
rather than 1.2.0cvs's
A_{|s}
or 1.1.6fix2's
A_{s}_{|}
But, in the situation
A|_{s}
pressing '_' should do the same as and take you to
A_{|s}
like 1.2.0cvs does.
Regards,
Eran Tromer
Re: super/subscript insets
On Wed, Jul 11, 2001 at 02:47:51PM +0200, Andre Poenitz wrote: > > Andre> - The \limit/\nolimit information is part of this inset. > > > > Note that this information only makes sense for some kind of elements > > (\mathop) before the *scripts. > > \underbrace seems to be another canditate... Or \limits after \sin And note that currently a subscript after \underbrace is rendered incorrectly.
Re: super/subscript insets
> And note that currently a subscript after \underbrace is rendered incorrectly. I know. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> LaTeX will choke on double scripts such as "A_{s}_{t}", so we can't have
> two script insets in sequence. But then, what happens if you have
> "A_{s}B_{t}"? and delete the B (e.g., in order to replace it by C)? The
> intermediate state would be the illegal "A_{s}_{t}", but we must allow
> it somehow. Possibilities:
> * Allow the sequential script insets and display them similarly to
> A_{s\,t}. Provide an informative error when exporting. This is the case
> now, except the error is LaTeX's.
> * Keep silent, export as "A_{s}{}_{t}". Problem: will be created
> unintentionally and go unnoticed.
> * In this special case, show an empty (blue) cell in front of the _{t},
> and export as "A_{s}{}_{t}" (empty cell = "{}").
Or make the base part of the inset ;-}
I just noticed that having the base _not_ part of an inset has another
disadvanage: in \sum_{} the subscript effectively determines
the width of the whole thing _and_ the position of the \sum char.
So rendering is no linear process anymore...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> Dekel> Or \limits after \sin > > \sin is a \mathop, right? > > Dekel> And note that currently a subscript after \underbrace is > Dekel> rendered incorrectly. > > In fact, \underbrace is a \mathop too. Mathed should know about which > insets/entities are mathops. Does this mean we basically have two things: - "ordinary" scriptinsets that appear after say 'a' or nothing that don't have \limit/\nolimit - mathops (\sum, \sin, \underbrace...) that can have su*scripts that could have \limit etc... ? If so, it would sound reasonable two implement thes two classes as seperate insets (that may share some code, but...) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Does this mean we basically have two things: Andre> - "ordinary" scriptinsets that appear after say 'a' or nothing Andre> that don't have \limit/\nolimit Andre> - mathops (\sum, \sin, \underbrace...) that can have su*scripts Andre> that could have \limit etc... Andre> ? Andre> If so, it would sound reasonable two implement thes two classes Andre> as seperate insets (that may share some code, but...) Yes, that may be a good idea. JMarc
Re: super/subscript insets
On Tue, Jul 10, 2001 at 04:53:55PM +0200, Andre Poenitz wrote: I have thought about the proper handling of super- and subscripts and came more or less to the conlusion that some kind of base has to be part of the inset. Three reasons for that: 1. I am not aware of too many situations where there is a *script on its own in a formula (one might argue with prepended scripts, but that's solvable). We do use that for faking text superscript/subscript (insert-special-char-subscript)
Re: super/subscript insets
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre I have thought about the proper handling of super- and Andre subscripts and came more or less to the conlusion that some Andre kind of base has to be part of the inset. Andre Three reasons for that: Andre 1. I am not aware of too many situations where there is a Andre *script on its own in a formula (one might argue with Andre prepended scripts, but that's solvable). I think some people do that in physics to have *scripts n the left of a symbol. Andre 2. In all most of the cases there is some kind of 'semantical Andre tie' between base and *script. So having the base as part of Andre the inset, anything related to semantics could be easier (think Andre of export to Maple/*) Yes, but this could be done via a distinct macro, as we discussed for integrals. I do not think that the maple export feature should force everybody to provide semantics. OTOH, one could argue that LyX is supposed to encourage semantics vs WYSIWYG. Andre 3. The implementation of drawing will be cleaner (no need to Andre look outside the inset to determine in which height the Andre superscript to draw) Remember that this is what TeX does, so you would be closer to its semantics. Andre A reason against that: Andre - The uservisible behaviour will change (i.e. when moving in Andre 'ab^c' it will take three right steps from the left- to the Andre rightmost position: One to go behind the a, one to enter the Andre inset (optically the same position), one to leave the inset. I think people will be pissed by this change, unless you can find a clever way to hide it (which seems difficult). JMarc PS: do you have plans to support the \big* family of delimiter modifiers?
Re: super/subscript insets
Another one against: - If the *script is part of the base inset, when you delete the base you delete the script too, which is not always what you want. On Tue, 10 Jul 2001, Andre Poenitz wrote: I have thought about the proper handling of super- and subscripts and came more or less to the conlusion that some kind of base has to be part of the inset. Three reasons for that: 1. I am not aware of too many situations where there is a *script on its own in a formula (one might argue with prepended scripts, but that's solvable). 2. In all most of the cases there is some kind of 'semantical tie' between base and *script. So having the base as part of the inset, anything related to semantics could be easier (think of export to Maple/*) 3. The implementation of drawing will be cleaner (no need to look outside the inset to determine in which height the superscript to draw) A reason against that: - The uservisible behaviour will change (i.e. when moving in 'ab^c' it will take three right steps from the left- to the rightmost position: One to go behind the a, one to enter the inset (optically the same position), one to leave the inset. Comments? Andre' -- André Pönitz . [EMAIL PROTECTED] -- Alejandro Aguilar Sierra [EMAIL PROTECTED]
Re: super/subscript insets
1. I am not aware of too many situations where there is a *script on its own in a formula (one might argue with prepended scripts, but that's solvable). We do use that for faking text superscript/subscript (insert-special-char-subscript) Math stuff is used outside mathed to fake something? Ok... I see. I think this does not hurt, the base could be invalid, i.e. not drawn at all (even not as an empty blue box) like we currently do for scriptinsets that do not have both sub- and superscript. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre 1. I am not aware of too many situations where there is a Andre *script on its own in a formula (one might argue with Andre prepended scripts, but that's solvable). I think some people do that in physics to have *scripts n the left of a symbol. The scriptinset could have up to five cells (including two for prepended super/subscript). Andre 2. In all most of the cases there is some kind of 'semantical Andre tie' between base and *script. So having the base as part of Andre the inset, anything related to semantics could be easier (think Andre of export to Maple/*) Yes, but this could be done via a distinct macro, as we discussed for integrals. I do not think that the maple export feature should force everybody to provide semantics. OTOH, one could argue that LyX is supposed to encourage semantics vs WYSIWYG. I do argue that way. Andre 3. The implementation of drawing will be cleaner (no need to Andre look outside the inset to determine in which height the Andre superscript to draw) Remember that this is what TeX does, so you would be closer to its semantics. *shrug* WYSIWYG vs WYSIWYM. Andre A reason against that: Andre - The uservisible behaviour will change (i.e. when moving in Andre 'ab^c' it will take three right steps from the left- to the Andre rightmost position: One to go behind the a, one to enter the Andre inset (optically the same position), one to leave the inset. I think people will be pissed by this change, unless you can find a clever way to hide it (which seems difficult). Not really. I can hide the step into the macro by checking whether we are in front of a scriptinset after a cursor-next. There is already script specific stuff in the cursor, so the harm is already done. PS: do you have plans to support the \big* family of delimiter modifiers? If anybody cares to explain me what the '\big* familiy of delimiter modifiers' is and if that is something that belongs to mathed and if it is needed and/or cute, we could make plans... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Another one against: - If the *script is part of the base inset, when you delete the base you delete the script too, which is not always what you want. Who says so? This depends on the return value(s) of idxDelete which can be overwritten for scriptinsets... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
Andre == Andre Poenitz [EMAIL PROTECTED] writes: PS: do you have plans to support the \big* family of delimiter modifiers? Andre If anybody cares to explain me what the '\big* familiy of Andre delimiter modifiers' is and if that is something that belongs Andre to mathed and if it is needed and/or cute, we could make Andre plans... They are used like: \bigl(...\bigm|...\bigr) (where \big can be replaced with \bigg, \Big, \Bigg). Basically, \left(...\right) is a frontend to those big delimiters, which selects automatically the right one (except that it is most of the time wrong and gives delimiters which are too big). This is not a top priority feature, anyway. I just wanted to mention it. JMarc
Re: super/subscript insets
Alejandro Aguilar Sierra wrote:
Another one against:
- If the *script is part of the base inset, when you delete the base you
delete the script too, which is not always what you want.
Well, in principle there's delete the whole inset, both base and
scripts and there's delete the base (put an empty blue box), leave the
scripts alone. Just like in \sqrt, for instance.
Two problems with this distinction. First, cursor position -- hard to
explain/draw cursor-at-the-left-of-base vs.
cursor-to-the-left-of-whole-inset. Second, extra cursor movement needed
to support this, and that would get very annoying.
Related issue: it must remain easy to take $X_{long+subscript}$ and
change the 'X' to 'Y'.
I can't think of any interface that preserves script semantics without
UI bloat.
Regards,
Eran Tromer
Re: super/subscript insets
On Tue, Jul 10, 2001 at 04:53:55PM +0200, Andre Poenitz wrote: > > I have thought about the proper handling of super- and subscripts and came > more or less to the conlusion that some kind of base has to be part of > the inset. > > Three reasons for that: > > 1. I am not aware of too many situations where there is a *script on its > own in a formula (one might argue with "prepended" scripts, but that's > solvable). We do use that for faking text superscript/subscript (insert->special-char->subscript)
Re: super/subscript insets
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> I have thought about the proper handling of super- and Andre> subscripts and came more or less to the conlusion that some Andre> kind of base has to be part of the inset. Andre> Three reasons for that: Andre> 1. I am not aware of too many situations where there is a Andre> *script on its own in a formula (one might argue with Andre> "prepended" scripts, but that's solvable). I think some people do that in physics to have *scripts n the left of a symbol. Andre> 2. In all most of the cases there is some kind of 'semantical Andre> tie' between base and *script. So having the base as part of Andre> the inset, anything related to semantics could be easier (think Andre> of export to Maple/*) Yes, but this could be done via a distinct macro, as we discussed for integrals. I do not think that the maple export feature should force everybody to provide semantics. OTOH, one could argue that LyX is supposed to encourage semantics vs WYSIWYG. Andre> 3. The implementation of drawing will be cleaner (no need to Andre> look outside the inset to determine in which height the Andre> superscript to draw) Remember that this is what TeX does, so you would be closer to its semantics. Andre> A reason against that: Andre> - The uservisible behaviour will change (i.e. when moving in Andre> 'ab^c' it will take three right steps from the left- to the Andre> rightmost position: One to go behind the a, one to enter the Andre> inset (optically the same position), one to leave the inset. I think people will be pissed by this change, unless you can find a clever way to hide it (which seems difficult). JMarc PS: do you have plans to support the \big* family of delimiter modifiers?
Re: super/subscript insets
Another one against: - If the *script is part of the base inset, when you delete the base you delete the script too, which is not always what you want. On Tue, 10 Jul 2001, Andre Poenitz wrote: > I have thought about the proper handling of super- and subscripts and came > more or less to the conlusion that some kind of base has to be part of > the inset. > > Three reasons for that: > > 1. I am not aware of too many situations where there is a *script on its > own in a formula (one might argue with "prepended" scripts, but that's > solvable). > > 2. In all most of the cases there is some kind of 'semantical tie' between > base and *script. So having the base as part of the inset, anything related > to semantics could be easier (think of export to Maple/*) > > 3. The implementation of drawing will be cleaner (no need to look outside > the inset to determine in which height the superscript to draw) > > A reason against that: > > - The uservisible behaviour will change (i.e. when moving in 'ab^c' it will > take three right steps from the left- to the rightmost position: One to > go behind the a, one to enter the inset (optically the same position), one > to leave the inset. > > Comments? > > Andre' > > -- > André Pönitz . [EMAIL PROTECTED] > -- Alejandro Aguilar Sierra [EMAIL PROTECTED]
Re: super/subscript insets
> > 1. I am not aware of too many situations where there is a *script on its > > own in a formula (one might argue with "prepended" scripts, but that's > > solvable). > > We do use that for faking text superscript/subscript > (insert->special-char->subscript) Math stuff is used outside mathed to fake something? Ok... I see. I think this does not hurt, the "base" could be "invalid", i.e. not drawn at all (even not as an empty blue box) like we currently do for scriptinsets that do not have both sub- and superscript. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> Andre> 1. I am not aware of too many situations where there is a > Andre> *script on its own in a formula (one might argue with > Andre> "prepended" scripts, but that's solvable). > > I think some people do that in physics to have *scripts n the left of > a symbol. The scriptinset could have up to five cells (including two for "prepended" super/subscript). > Andre> 2. In all most of the cases there is some kind of 'semantical > Andre> tie' between base and *script. So having the base as part of > Andre> the inset, anything related to semantics could be easier (think > Andre> of export to Maple/*) > > Yes, but this could be done via a distinct macro, as we discussed for > integrals. I do not think that the maple export feature should force > everybody to provide semantics. OTOH, one could argue that LyX is > supposed to encourage semantics vs WYSIWYG. I do argue that way. > Andre> 3. The implementation of drawing will be cleaner (no need to > Andre> look outside the inset to determine in which height the > Andre> superscript to draw) > > Remember that this is what TeX does, so you would be closer to its > semantics. *shrug* WYSIWYG vs WYSIWYM. > Andre> A reason against that: > > Andre> - The uservisible behaviour will change (i.e. when moving in > Andre> 'ab^c' it will take three right steps from the left- to the > Andre> rightmost position: One to go behind the a, one to enter the > Andre> inset (optically the same position), one to leave the inset. > > I think people will be pissed by this change, unless you can find a > clever way to hide it (which seems difficult). Not really. I can hide the step into the macro by checking whether we are in front of a scriptinset after a cursor->next. There is already script specific stuff in the cursor, so the harm is already done. > PS: do you have plans to support the \big* family of delimiter modifiers? If anybody cares to explain me what the '\big* familiy of delimiter modifiers' is and if that is something that belongs to mathed and if it is needed and/or cute, we could make plans... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> Another one against: > - If the *script is part of the base inset, when you delete the base you > delete the script too, which is not always what you want. Who says so? This depends on the return value(s) of idxDelete which can be overwritten for scriptinsets... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: super/subscript insets
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> PS: do you have plans to support the \big* family of delimiter >> modifiers? Andre> If anybody cares to explain me what the '\big* familiy of Andre> delimiter modifiers' is and if that is something that belongs Andre> to mathed and if it is needed and/or cute, we could make Andre> plans... They are used like: \bigl(...\bigm|...\bigr) (where \big can be replaced with \bigg, \Big, \Bigg). Basically, \left(...\right) is a frontend to those big delimiters, which selects automatically the right one (except that it is most of the time wrong and gives delimiters which are too big). This is not a top priority feature, anyway. I just wanted to mention it. JMarc
Re: super/subscript insets
Alejandro Aguilar Sierra wrote:
>
> Another one against:
> - If the *script is part of the base inset, when you delete the base you
> delete the script too, which is not always what you want.
Well, in principle there's "delete the whole inset, both base and
scripts" and there's "delete the base (put an empty blue box), leave the
scripts alone". Just like in \sqrt, for instance.
Two problems with this distinction. First, cursor position -- hard to
explain/draw cursor-at-the-left-of-base vs.
cursor-to-the-left-of-whole-inset. Second, extra cursor movement needed
to support this, and that would get very annoying.
Related issue: it must remain easy to take $X_{long+subscript}$ and
change the 'X' to 'Y'.
I can't think of any interface that preserves script semantics without
UI bloat.
Regards,
Eran Tromer
