See https://www.lyx.org/trac/ticket/13069
On Sat, May 25, 2024, at 4:28 AM, Pavel Sanda wrote:
> On Fri, May 24, 2024 at 01:35:28PM -0400, Alexander Dunlap wrote:
> > >>> I can reproduce this. I investigated a little and it seems that the
> > >>> problem is that the "while (true)" loop in the spl
On Fri, May 24, 2024 at 01:35:28PM -0400, Alexander Dunlap wrote:
> >>> I can reproduce this. I investigated a little and it seems that the
> >>> problem is that the "while (true)" loop in the splitAndWrapInMText
> >>> function in InsetMathBox.cpp is never terminating. I believe that the
> >>> r
t;
>>>> Following is the math block which caused it, (LyX code)
>>>> \begin_inset Formula
>>>> \[
>>>> \boxed{v=\left[v_{p}\right]_{a_{0}}}
>>>> \]
>>>> \end_inset
>>>>
>>>> The file is also attache
v_{p}\right]_{a_{0}}}
>>> \]
>>> \end_inset
>>>
>>> The file is also attached in the end and here is the screenshot of the math
>>> block.
>>> Screenshot from 2024-05-18 11-43-00.png
>>>
>>> It is a legitimate construction an
also attached in the end and here is the screenshot of
the math block.
Screenshot from 2024-05-18 11-43-00.png
It is a legitimate construction and it gives no problem in LyX-2.3.7
(confirmed).
If either the box is removed or the subscript 0 is removed from /a/,
then it has no issues in copying
k.
>> Screenshot from 2024-05-18 11-43-00.png
>>
>> It is a legitimate construction and it gives no problem in LyX-2.3.7
>> (confirmed).
>> If either the box is removed or the subscript 0 is removed from *a*, then it
>> has no issues in copying.
>&
; \]
> \end_inset
>
> The file is also attached in the end and here is the screenshot of the math
> block.
> Screenshot from 2024-05-18 11-43-00.png
>
> It is a legitimate construction and it gives no problem in LyX-2.3.7
> (confirmed).
> If either the box is removed
gives no problem in LyX-2.3.7
(confirmed).
If either the box is removed or the subscript 0 is removed from *a*, then
it has no issues in copying.
All these versions I mentioned were compiled from source on Gentoo Linux.
This LyX-2.4 was compiled with the following configuration,
$ ./configure
Le 16/04/2024 à 18:44, Jürgen Spitzmüller a écrit :
Am Dienstag, dem 16.04.2024 um 12:08 +0200 schrieb Jean-Marc
Lasgouttes:
I propose the following patch. Can you check that it works?
Works for me with both testcases.
Thanks for testing, it is now in master. Riki, I think it is worth
backp
On Tue, Apr 16, 2024 at 06:44:25PM GMT, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 16.04.2024 um 12:08 +0200 schrieb Jean-Marc
> Lasgouttes:
> > I propose the following patch. Can you check that it works?
>
> Works for me with both testcases.
Works well here. Thanks!
Scott
signature.asc
Desc
Am Dienstag, dem 16.04.2024 um 12:08 +0200 schrieb Jean-Marc
Lasgouttes:
> I propose the following patch. Can you check that it works?
Works for me with both testcases.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 4/16/24 06:08, Jean-Marc Lasgouttes wrote:
Le 13/04/2024 à 08:10, Jürgen Spitzmüller a écrit :
Note that this is not specific to this particularly inset. I can
reproduce with any other (text) inset, e.g.:
1. Start a new document.
2. Insert a Note inset
3. Save the (new) file (cursor still be
Le 13/04/2024 à 08:10, Jürgen Spitzmüller a écrit :
Note that this is not specific to this particularly inset. I can
reproduce with any other (text) inset, e.g.:
1. Start a new document.
2. Insert a Note inset
3. Save the (new) file (cursor still being in the Note inset).
=> Kaboom.
What happ
On Sat, Apr 13, 2024 at 08:10:59AM GMT, Jürgen Spitzmüller wrote:
> Am Freitag, dem 12.04.2024 um 12:06 -0400 schrieb Scott Kostyshak:
> > To reproduce:
> >
> > 1. Start a new document.
> > 2. Start a math inset, e.g., ctrl + m.
> > 3. Type "x".
>
Am Freitag, dem 12.04.2024 um 12:06 -0400 schrieb Scott Kostyshak:
> To reproduce:
>
> 1. Start a new document.
> 2. Start a math inset, e.g., ctrl + m.
> 3. Type "x".
> 4. Press "_" to go into the subscript.
> 5. Type "i" (so at this ste
To reproduce:
1. Start a new document.
2. Start a math inset, e.g., ctrl + m.
3. Type "x".
4. Press "_" to go into the subscript.
5. Type "i" (so at this step the math will be $x_i$).
6. Save the (new) file.
After saving, I get a SIGSEGV.
Note that to reproduce, a
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> > http://bugzilla.lyx.org/show_bug.cgi?id=4117
>
> I took the liberty to commit that one too.
OK.
Jürgen
Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=4117
I took the liberty to commit that one too.
Abdel.
http://bugzilla.lyx.org/show_bug.cgi?id=4117
Index: Cursor.cpp
===
--- Cursor.cpp (revision 19634)
+++ Cursor.cpp (working copy)
@@ -1482,12 +1482,14 @@
}
-void Cursor::fixIfBroken()
+bool Cursor::fixIfBroken()
{
if (D
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> - in MathScriptInset::notifyCursorLeave, there were no
>> recordUndoInset calls. This fix seems safe and obvious to me
Andre> Worst case scenario is that an additional C-z is needed to undo
Andre> stuff. Could be mildly annoying if it
On Mon, Aug 14, 2006 at 05:21:49PM +0200, Jean-Marc Lasgouttes wrote:
>
> The following patch fixes this bug for me. However I have questions
> about whether I did it right.
>
> There are 3 mostly independent parts in the patch:
>
> - in MathScriptInset::notifyCursorLeave, there were no recordUn
On Wed, Aug 16, 2006 at 04:44:34AM +0200, Enrico Forestieri wrote:
> On Mon, Aug 14, 2006 at 05:21:49PM +0200, Jean-Marc Lasgouttes wrote:
>
> > The following patch fixes this bug for me.
>
> Indeed, the crash is gone. However, after applying this patch I still
> observe a weird behavior which ma
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> On Thu, Aug 17, 2006 at 09:55:09PM +0200, Jean-Marc Lasgouttes
Enrico> wrote:
>> OK, this new patch fixes this problem too.
Enrico> This is excellent, JMarc!
Enrico> I was not able to trigger any weird behavior and I like a
On Thu, Aug 17, 2006 at 09:55:09PM +0200, Jean-Marc Lasgouttes wrote:
> OK, this new patch fixes this problem too.
This is excellent, JMarc!
I was not able to trigger any weird behavior and I like a lot the
automatic removal/addition of the brace inset. An improvement over
a bug fix, IMHO.
--
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
I applied all the bits except for this latest patch. I attach the
remaining bits.
Jean-Marc> OK, this new patch fixes this problem too. There are two
Jean-Marc> parts:
Jean-Marc> - easy one: export x^2, but {xy}^2 and {x^{2}}^
os << "^{" << up() << '}';
if (lock_ && !os.latex())
@@ -552,7 +557,7 @@ void MathScriptInset::infoize2(std::ostr
}
-void MathScriptInset::notifyCursorLeaves(LCursor & cur)
+bool MathScriptInset::notifyCursorLeaves(LCursor & c
Jean-Marc Lasgouttes wrote:
> Yes, probably. I am not sure whether the part that deals with script
> insets is still useful (but it may).
I leave it to you, since you have your hands in the code nevertheless, and I'm
leaving for holidays the day after tomorrow.
Jürgen
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> This patch fixes it. However, as I am a bad guy, I found
Enrico> another problem ;-) (I wish I have a better grasp of the
Enrico> sources such that to be helpful instead of simply reporting
Enrico> misbehavior)
I am glad to s
ld be
Georg> different with other bases than \sum.
Since it is visible on screen, I am not too worried about this.
>> All my patch does is remove empty cells when notifyCursorLeaves is
>> called. If I leave the cell by clicking somewhere else, the method
>> is not invoked and the
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> -void MathNestInset::notifyCursorLeaves(LCursor & cur) +bool
>> MathNestInset::notifyCursorLeaves(LCursor & cur) { #ifdef
>> WITH_WARNINGS #warning look here @@ -373,6 +373,7 @@ void
>> M
Jean-Marc Lasgouttes wrote:
> -void MathNestInset::notifyCursorLeaves(LCursor & cur)
> +bool MathNestInset::notifyCursorLeaves(LCursor & cur)
> {
> #ifdef WITH_WARNINGS
> #warning look here
> @@ -373,6 +373,7 @@ void MathNestInset::notifyCursorLeaves(L
> }
> }
> #endif
>
sum_{}xxx" works fine and gives the same output as "\sum xxx",
but I would not be surprised if that would be different with other bases
than \sum.
> All my patch does is remove empty cells when notifyCursorLeaves is
> called. If I leave the cell by clicking somewhere else, the met
Inset::infoize2(std::ostr
}
-void MathScriptInset::notifyCursorLeaves(LCursor & cur)
+bool MathScriptInset::notifyCursorLeaves(LCursor & cur)
{
MathNestInset::notifyCursorLeaves(cur);
@@ -563,17 +564,34 @@ void MathScriptInset::notifyCursorLeaves
// Case of two scripts. In this ca
On Thu, Aug 17, 2006 at 01:13:37PM +0200, Jean-Marc Lasgouttes wrote:
> OK, I see it indeed. What happens is that, when the script inset
> deletes its superscript, all that remains is a script inset with only
> one cell. Any undo concerning this inset will contain only the script
> "x", which is p
ve the cell by clicking somewhere else, the method is
not invoked and the empty subscript remains. But in this case, there
is a blue rectangle showing the empty superscript, so people know
about it.
If I click outside of the math inset LyX crashes :) I'll have a look.
Georg> Can you
Jean-Marc Lasgouttes wrote:
> Actually, when it does not have any script, the script inset should
> commit suicide and replace itself with its contents.
IIRC we have that in bugzilla.
> This is what this
> updated patch does. I checked that it works and valgrind does not
> complain.
>
> Please
asUp() && up().size())
+ if (hasUp() /*&& up().size()*/)
os << "^{" << up() << '}';
if (lock_ && !os.latex())
@@ -563,15 +564,28 @@ void MathScriptInset::notifyCursorLeaves
// Case of two scripts. In this case, 1 = super, 2 =
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> Indeed, the crash is gone. However, after applying this patch
Enrico> I still observe a weird behavior which may be reproduced by
Enrico> the following steps:
Enrico> 1) Ctrl-N (new document) 2) Shift-Ctrl-M (math display) 3)
Enrico Forestieri wrote:
> Omitting step 6 above, everything is ok. So, maybe I am only being picky.
No, it is good you found that out. Neither navigating with the cursor keys
around nor undo/redo should ever produce such an infinite loop. I guess the
reason is similar to the one of the fixed pro
On Mon, Aug 14, 2006 at 05:21:49PM +0200, Jean-Marc Lasgouttes wrote:
> The following patch fixes this bug for me.
Indeed, the crash is gone. However, after applying this patch I still
observe a weird behavior which may be reproduced by the following steps:
1) Ctrl-N (new document)
2) Shift-Ctrl
size())
+ if (hasUp() /*&& up().size()*/)
os << "^{" << up() << '}';
if (lock_ && !os.latex())
@@ -563,15 +564,18 @@ void MathScriptInset::notifyCursorLeaves
// Case of two scripts. In this case, 1 = super, 2 = sub
if (cur.idx() == 2
Jean-Pierre Chretien wrote:
> Hello,
>
> I don't know if this is related to bug #2582, but here it is.
> Given the math construct A_iB_j, if I set the cursor between i and B
> and type backspace, the j subscript disappears.
>
> This true only if I come back in the expr
Hello,
I don't know if this is related to bug #2582, but here it is.
Given the math construct A_iB_j, if I set the cursor between i and B
and type backspace, the j subscript disappears.
This true only if I come back in the expression to edit it: if I do the
same operation when I creat
On Mon, 2006-03-13 at 11:27 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Corrects faulty logic for deleting empty sub/super scripts on
> Martin> leaving them.
>
> Martin> Was tested by me and Georg, and does the job.
>
> Martin> OK
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Corrects faulty logic for deleting empty sub/super scripts on
Martin> leaving them.
Martin> Was tested by me and Georg, and does the job.
Martin> OK to commit to both trunk and 1.4.x?
OK for 1.4.x.
JMarc
On Sat, Mar 11, 2006 at 04:37:08PM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | Corrects faulty logic for deleting empty sub/super scripts on
> | leaving them.
> |
> | Was tested by me and Georg, and does the job.
> |
> | OK to commit to both trunk and 1.
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Corrects faulty logic for deleting empty sub/super scripts on
| leaving them.
|
| Was tested by me and Georg, and does the job.
|
| OK to commit to both trunk and 1.4.x?
Ok for trunk.
--
Lgb
(revision 13312)
+++ math_scriptinset.C (working copy)
@@ -560,9 +560,15 @@
// remove empty scripts if possible
if (1) {
- if (nargs() > 2 && cur.idx() == 2 && cell(2).empty()) {
- // must be a subscript...
- removeScript(false);
+
John C. McCabe-Dansted wrote:
> I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following
> steps I get a crash.
>
> 1. Enter mathmode
> 2. type: T_E X
> 3. move the cursor before the E
> 4. press delete
> 5. press the up arrow twice.
There's already a report for this on
I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following
steps I get a crash.
1. Enter mathmode
2. type: T_E X
3. move the cursor before the E
4. press delete
5. press the up arrow twice.
This bug does not occur in 1.4.0pre3.
My system: Kubuntu 5.10, gcc 4.02, QT 3.3.
ng
> > >> delimiters is _hard_ because once again, the cursor is _displayed_
> > >> in front of the delimiters while the action takes place inside.
> >
> > Georg> I dodn't know what happens here.
> >
> > It may be related to the patch that Jue
limiters while the action takes place inside.
>
> Georg> I dodn't know what happens here.
>
> It may be related to the patch that Juergen sent about using cursorPos
> in non HIGLY_EDITABLE insets.
>
I just found that I can't insert a matrix into a subscript - lyx just
i
On Wed, Apr 07, 2004 at 02:11:50PM +0200, Georg Baum wrote:
> Angus Leeming wrote:
>
> > The display of subscripts in this file created by lyx 13x is foobarred
> > when viewed with lyx 14x. Andre, I suspect that this is your
>
> Not only the view is wrong, the same stuff is written to the .lyx fi
Angus Leeming wrote:
> The display of subscripts in this file created by lyx 13x is foobarred
> when viewed with lyx 14x. Andre, I suspect that this is your
Not only the view is wrong, the same stuff is written to the .lyx file if
you save it.
> re-definition of which cell means what. Have you i
On Wed, Apr 07, 2004 at 10:29:36AM +0100, Angus Leeming wrote:
> The display of subscripts in this file created by lyx 13x is foobarred
> when viewed with lyx 14x. Andre, I suspect that this is your
> re-definition of which cell means what. Have you introduced a format
> change?
No. It's still LaT
The display of subscripts in this file created by lyx 13x is foobarred
when viewed with lyx 14x. Andre, I suspect that this is your
re-definition of which cell means what. Have you introduced a format
change?
--
Angus
trial.lyx
Description: application/lyx
On Fri, Dec 12, 2003 at 09:40:57PM +0200, Martin Vermeer wrote:
> On Fri, Dec 12, 2003 at 02:59:27PM +0100, Andre Poenitz spake thusly:
>
> > + if (c == '_') {
> > + script(false);
> > + return true;
> > + }
> > +
> > + if (c == '^') {
> > + script(true);
> > +
Martin Vermeer wrote:
> ...and with the attached also the math panel sub/superscript buttons
> will work again ;-)
Applied.
--
Angus
On Fri, Dec 12, 2003 at 02:59:27PM +0100, Andre Poenitz spake thusly:
> + if (c == '_') {
> + script(false);
> + return true;
> + }
> +
> + if (c == '^') {
> + script(true);
> + return true;
> + }
...and with the attached also the ma
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: lyx_main.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_m
On Sun, Dec 07, 2003 at 01:46:47PM +0100, Christian Ridderström wrote:
> Hi
>
> Have the method of getting subscripts changed or something in 1.4 xforms?
> When I press '_' I actually get a '_' instead of a subscript?
> (Same thing goes for superscripts, &#x
Hi
Have the method of getting subscripts changed or something in 1.4 xforms?
When I press '_' I actually get a '_' instead of a subscript?
(Same thing goes for superscripts, '^' inserts a '^' :-(
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
On Tue, Jul 10, 2001 at 05:37:13PM +0200, Jean-Marc Lasgouttes wrote:
> 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> A reason against that:
>
>
insert->special character->super/subscript works well.
but when you click anywhere in the text and than
between the two parenthesis in the mathbox of the
super/subscript the text of the super/sub will be
deleted _and_ undo doesn't work!
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
> "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
* 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.
> >
>
> "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
Andr
> 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 m
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
> And note that currently a subscript after \underbrace is rendered incorrectly.
I know.
Andre'
--
André Pönitz . [EMAIL PROTECTED]
ace seems to be another canditate...
Or \limits after \sin
And note that currently a subscript after \underbrace is rendered incorrectly.
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 orde
> 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 . [EMA
> "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 ele
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
info
> Interesting.
>
> For "$foo{X_{s}}bar$", that would mean:
> * cursor to the left of "X_{s}" -> whole formula highlighted
Well... just a frame. Not a solid box..
> * cursor to the left of "X" -> just "X" highlighted
> There's no case where "X_{s}" gets highlighed, so there's no indication
>
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
> 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 .
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
> "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
> 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 ..
> 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> th
> > 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-&
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 con
> "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
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)
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 "p
Dekel Tsur wrote:
> This is a general problem with math-insert, and I reported this bug in my
> mathed bug list. However, I decided to be more productive, so I fixed this
> bug myself.
Works.
Thanks,
Garst
On Fri, Jul 06, 2001 at 08:08:17PM -0300, Garst R. Reese wrote:
> "Garst R. Reese" wrote:
> >
> > Insert->Special Character->Subscript
> > Gives me a centered red box with a blue math box and a blue (#) in lyx
> > and a centered subscript with an equa
"Garst R. Reese" wrote:
>
> Insert->Special Character->Subscript
> Gives me a centered red box with a blue math box and a blue (#) in lyx
> and a centered subscript with an equation number in ps.
> All I want is a text mode subscript in line like V(sub)n.
> Ga
Insert->Special Character->Subscript
Gives me a centered red box with a blue math box and a blue (#) in lyx
and a centered subscript with an equation number in ps.
All I want is a text mode subscript in line like V(sub)n.
Garst
On Wed, 4 Jul 2001, Andre Poenitz wrote:
> > > It's possible to create a double subscript by typing the following in
> > > mathed:
> > > x_1y_2
> >
> > the y is a typo???
>
> No, I can confirm the bug.
>
> I have a work around in my
> > It's possible to create a double subscript by typing the following in
> > mathed:
> > x_1y_2
>
> the y is a typo???
No, I can confirm the bug.
I have a work around in my local tree, but the whole business of
super/subscripts seems to need a bit of work...
Herbert Voss wrote:
>
> Eran Tromer wrote:
> >
> > It's possible to create a double subscript by typing the following in
> > mathed:
> > x_1y_2
>
> the y is a typo???
No it's not. I'm writing
x y
1 2
and then I delete the 'y'.
Regards,
Eran Tromer
Eran Tromer wrote:
>
> It's possible to create a double subscript by typing the following in
> mathed:
> x_1y_2
the y is a typo???
> The generated latex code contains "x_{1}_{2}", and so does the saved
> .lyx file.
x_{1_{2_{3}}}
this is my code, same in 1
Hello,
It's possible to create a double subscript by typing the following in
mathed:
x_1y_2
The generated latex code contains "x_{1}_{2}", and so does the saved
.lyx file.
The bug exists in the current 1.2.0cvs, and the double subscript is
displayed just like "x_{12}&qu
On Fri, Jun 22, 2001 at 10:02:40AM +0200, Markus Mohr wrote:
> Hi!
>
> Version: 1.1.6fix2
>
> If I create a subscript behind a greek character and this character is
> the first in an itemize environment, the subscript is before the
> character not behind it.
I can't
Hi!
Version: 1.1.6fix2
If I create a subscript behind a greek character and this character is
the first in an itemize environment, the subscript is before the
character not behind it.
ciao
marksu
couple of years ago, and it was fixed. Now
It's back. In the fourth line of the multiline equation in 1., something
has a double subscript. It's not visible in LyX, but it makes
LaTeX choke.
I'm assumint that it is the
p_{i}_{i}\mu
hawk
#LyX 1.2 created this file. For more in
Maybe we should add the subscript/superscript to LyX to provide it easily
(and possibly with the correct on screen view).
This is an often asked question (and should be put in the FAQ)
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://www.redrival.com/jindor
1 - 100 of 141 matches
Mail list logo
