Bug: Small mathed annoyance.
Hi,
The bug applies to 1.3.0pre3, whith any frontend.
The attached file contains some gather math environments. It could be any
math environment with multiple rows, eg. eqnarray.
In any of them, try to select with the mouse the whole middle row. As you
move the mouse (with the first button pressed), the first or the third row
also get selected, ie. there is no central range to place the pointer
such that the selection takes place only in the middle row.
Note that there is a central line in the middle row. If the cursor is
above it, then the first row gets selected; if the cursor is below it,
then the third row gets selected. _But_, the line is not centered in the
middle row, it is half cursor below its center, which constitutes another
feature of the bug.
The problem is not serious because if you continue to move the mouse to
the end of the middle row, then the selection becomes only on it, but it
is annoying and can confuse beginners.
André, if you want me to file a bug in bugzilla, please suggest a Summary
that can identify it. I can't even describe it well!
Regards,
João.
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Formula \begin{gather*}
aaa\\
\left(aa\right)\\
aaa\end{gather*}
\end_inset
\begin_inset Formula \begin{gather*}
aaa\\
\frac{aaa}{aaa}\\
aaa\end{gather*}
\end_inset
\begin_inset Formula \begin{gather*}
aaa\\
\overbrace{aaa}\\
aaa\end{gather*}
\end_inset
\the_end
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 09:08:03AM -0200, Joao Luis Meloni Assirati wrote: The attached file contains some gather math environments. It could be any math environment with multiple rows, eg. eqnarray. In any of them, try to select with the mouse the whole middle row. As you move the mouse (with the first button pressed), the first or the third row also get selected, ie. there is no central range to place the pointer such that the selection takes place only in the middle row. Well, it certainly works if you click inside the contents of the middle row and draw the mouse just left or right. There seems to be a problem if you click to far to the left or to the right and do not move the mouse far enough but I have difficulties to see this as a bug as this works as intended: You have a single inset in the middle row, so if you place the selection anchor outside, the cursor can't go inside lest we would have partial insets. Now the cursor is places as close as legally possible, which, in your case is the line above or below. The problem is not serious because if you continue to move the mouse to the end of the middle row, then the selection becomes only on it, but it is annoying and can confuse beginners. Show me a couple of them and tell me how to handle partial insets. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Bug: Small mathed annoyance.
On Tue, 4 Feb 2003, Andre Poenitz wrote: [...] You have a single inset in the middle row, so if you place the selection anchor outside, the cursor can't go inside lest we would have partial insets. Now the cursor is places as close as legally possible, which, in your case is the line above or below. [...] Show me a couple of them and tell me how to handle partial insets. Sorry, I didn't myself clear. I don't want partial insets, and doubt that they would be useful. What I was trying to say is that the cursor should not jump to the first or the third rows while you move the mouse. That is, while you move the mouse over the inset, the cursor should be at the end of the inset. Otherwise, if while dragging you move the mouse outside the inset, perhaps going over the first or the third rows, then and only then the first or the third rows should be selected. Think about a newbie that starts to copy a large inset. He starts to move the mouse and not only the whole inset gets imediately selected (which is natural), but also neighbour insets. As he moves the mouse, more undesired things will be selected. He will be confused and stop what he was trying to do unless he knows that if he goes farther, then suddenly less things will be selected. This is not critical, of course. Anyone can get used with this behavior. Thank you, João.
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 10:31:52AM -0200, Joao Luis Meloni Assirati wrote: Sorry, I didn't myself clear. I don't want partial insets, and doubt that they would be useful. What I was trying to say is that the cursor should not jump to the first or the third rows while you move the mouse. But that's the nearest acceptable position given that it is not allowed to go inside the second row. That is, while you move the mouse over the inset, the cursor should be at the end of the inset. Certainly not. First of all, you could select from behind. Secondly, the cursor should be somehow near the mouse pointer, everything else is _really_ confusing. And as insets can span the whole width of the screen, placing the cursor on the far end is not a very practical option. Think about a newbie that starts to copy a large inset. He starts to move the mouse and not only the whole inset gets imediately selected (which is natural), but also neighbour insets. I guess if he is surprised, he will move the mouse pointer around a bit and quickly notice that he has just to go far enough to the left or to the right to get what he wants. As he moves the mouse, more undesired things will be selected. He will be confused and stop what he was trying to do unless he knows that if he goes farther, then suddenly less things will be selected. Note that farther means something like 2 or 3mm on an ordinary screen. This is not critical, of course. Anyone can get used with this behavior. I think so, and I think alternatives are worse. Much worse. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Bug: Small mathed annoyance.
On Tue, 4 Feb 2003, Andre Poenitz wrote: On Tue, Feb 04, 2003 at 10:31:52AM -0200, Joao Luis Meloni Assirati wrote: That is, while you move the mouse over the inset, the cursor should be at the end of the inset. Certainly not. First of all, you could select from behind. OK. At the opposite end, then. Secondly, the cursor should be somehow near the mouse pointer, everything else is _really_ confusing. Well, IMHO some position in another line can be geometricaly nearer, but not logicaly nearer, as the cursor needs to walk more to get to another line. And as insets can span the whole width of the screen, placing the cursor on the far end is not a very practical option. This seems to be an argument against the current way, as it would be better in this case if I didn't have to reach the end of the inset to select it. Observe that this is not the behavior outside math. For example, if you have three displayed equations stacked (like the example file I sent), marking the middle one with the mouse will behave like I'm proposing, ie. the cursor does not jump to the first or the third displayed equation, but to the end of the middle. Regards, João.
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 12:10:50PM -0200, Joao Luis Meloni Assirati wrote: Secondly, the cursor should be somehow near the mouse pointer, everything else is _really_ confusing. Well, IMHO some position in another line can be geometricaly nearer, but not logicaly nearer, as the cursor needs to walk more to get to another line. We could penalize vertical distances. But I think the principle is sound. placing the cursor on the far end is not a very practical option. This seems to be an argument against the current way, as it would be better in this case if I didn't have to reach the end of the inset to select it. Observe that this is not the behavior outside math. It is much easier to get it right if you have rectangular grid with equally sized items (aka chars in rows in paragraphs). For example, if you have three displayed equations stacked (like the example file I sent), marking the middle one with the mouse will behave like I'm proposing, ie. the cursor does not jump to the first or the third displayed equation, but to the end of the middle. Yes. But in the outside world there is no way to select two chars in adjacent rows (like vi's block mode C-v). The situation _is_ different there. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Bug: Small mathed annoyance.
Hi,
The bug applies to 1.3.0pre3, whith any frontend.
The attached file contains some gather math environments. It could be any
math environment with multiple rows, eg. eqnarray.
In any of them, try to select with the mouse the whole middle row. As you
move the mouse (with the first button pressed), the first or the third row
also get selected, ie. there is no "central range" to place the pointer
such that the selection takes place only in the middle row.
Note that there is a "central line" in the middle row. If the cursor is
above it, then the first row gets selected; if the cursor is below it,
then the third row gets selected. _But_, the line is not centered in the
middle row, it is half cursor below its center, which constitutes another
"feature" of the bug.
The problem is not serious because if you continue to move the mouse to
the end of the middle row, then the selection becomes only on it, but it
is annoying and can confuse beginners.
André, if you want me to file a bug in bugzilla, please suggest a Summary
that can identify it. I can't even describe it well!
Regards,
João.
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Formula \begin{gather*}
aaa\\
\left(aa\right)\\
aaa\end{gather*}
\end_inset
\begin_inset Formula \begin{gather*}
aaa\\
\frac{aaa}{aaa}\\
aaa\end{gather*}
\end_inset
\begin_inset Formula \begin{gather*}
aaa\\
\overbrace{aaa}\\
aaa\end{gather*}
\end_inset
\the_end
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 09:08:03AM -0200, Joao Luis Meloni Assirati wrote: > The attached file contains some gather math environments. It could be any > math environment with multiple rows, eg. eqnarray. > > In any of them, try to select with the mouse the whole middle row. As you > move the mouse (with the first button pressed), the first or the third row > also get selected, ie. there is no "central range" to place the pointer > such that the selection takes place only in the middle row. Well, it certainly works if you click inside the contents of the middle row and draw the mouse just left or right. There seems to be a "problem" if you click to far to the left or to the right and do not move the mouse far enough but I have difficulties to see this as a bug as this works as intended: You have a single inset in the middle row, so if you place the selection anchor outside, the cursor can't go inside lest we would have "partial insets". Now the cursor is places "as close as legally possible", which, in your case is the line above or below. > The problem is not serious because if you continue to move the mouse to > the end of the middle row, then the selection becomes only on it, but it > is annoying and can confuse beginners. Show me a couple of them and tell me how to handle "partial insets". Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Bug: Small mathed annoyance.
On Tue, 4 Feb 2003, Andre Poenitz wrote: [...] > You have a single inset in the middle row, so if you place the > selection anchor outside, the cursor can't go inside lest we would have > "partial insets". Now the cursor is places "as close as legally possible", > which, in your case is the line above or below. > [...] > Show me a couple of them and tell me how to handle "partial insets". Sorry, I didn't myself clear. I don't want "partial insets", and doubt that they would be useful. What I was trying to say is that the cursor should not jump to the first or the third rows while you move the mouse. That is, while you move the mouse over the inset, the cursor should be at the end of the inset. Otherwise, if while dragging you move the mouse outside the inset, perhaps going over the first or the third rows, then and only then the first or the third rows should be selected. Think about a newbie that starts to copy a large inset. He starts to move the mouse and not only the whole inset gets imediately selected (which is natural), but also neighbour insets. As he moves the mouse, more undesired things will be selected. He will be confused and stop what he was trying to do unless he knows that if he goes farther, then suddenly less things will be selected. This is not critical, of course. Anyone can get used with this behavior. Thank you, João.
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 10:31:52AM -0200, Joao Luis Meloni Assirati wrote: > Sorry, I didn't myself clear. I don't want "partial insets", and doubt > that they would be useful. What I was trying to say is that the cursor > should not jump to the first or the third rows while you move the mouse. But that's the nearest acceptable position given that it is not allowed to go inside the second row. > That is, while you move the mouse over the inset, the cursor should be at > the end of the inset. Certainly not. First of all, you could select from behind. Secondly, the cursor should be "somehow near" the mouse pointer, everything else is _really_ confusing. And as insets can span the whole width of the screen, placing the cursor on the far end is not a very practical option. > Think about a newbie that starts to copy a large inset. He starts to move > the mouse and not only the whole inset gets imediately selected (which is > natural), but also neighbour insets. I guess if he is surprised, he will move the mouse pointer around a bit and quickly notice that he has just to go far enough to the left or to the right to get what he wants. > As he moves the mouse, more undesired things will be selected. He will > be confused and stop what he was trying to do unless he knows that if he > goes farther, then suddenly less things will be selected. Note that "farther" means something like 2 or 3mm on an ordinary screen. > This is not critical, of course. Anyone can get used with this behavior. I think so, and I think alternatives are worse. Much worse. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Bug: Small mathed annoyance.
On Tue, 4 Feb 2003, Andre Poenitz wrote: > On Tue, Feb 04, 2003 at 10:31:52AM -0200, Joao Luis Meloni Assirati wrote: > > That is, while you move the mouse over the inset, the cursor should be at > > the end of the inset. > > Certainly not. First of all, you could select from behind. OK. At the opposite end, then. > Secondly, the > cursor should be "somehow near" the mouse pointer, everything else is > _really_ confusing. Well, IMHO some position in another line can be geometricaly nearer, but not logicaly nearer, as the cursor needs to "walk more" to get to another line. > And as insets can span the whole width of the screen, > placing the cursor on the far end is not a very practical option. This seems to be an argument against the current way, as it would be better in this case if I didn't have to reach the end of the inset to select it. Observe that this is not the behavior outside math. For example, if you have three displayed equations stacked (like the example file I sent), marking the middle one with the mouse will behave like I'm proposing, ie. the cursor does not jump to the first or the third displayed equation, but to the end of the middle. Regards, João.
Re: Bug: Small mathed annoyance.
On Tue, Feb 04, 2003 at 12:10:50PM -0200, Joao Luis Meloni Assirati wrote: > > Secondly, the > > cursor should be "somehow near" the mouse pointer, everything else is > > _really_ confusing. > > Well, IMHO some position in another line can be geometricaly nearer, but > not logicaly nearer, as the cursor needs to "walk more" to get to another > line. We could penalize vertical distances. But I think the principle is sound. > > placing the cursor on the far end is not a very practical option. > > This seems to be an argument against the current way, as it would be > better in this case if I didn't have to reach the end of the inset to > select it. > > Observe that this is not the behavior outside math. It is much easier to "get it right" if you have rectangular grid with equally sized items (aka chars in rows in paragraphs). > For example, if you have three displayed equations stacked (like the > example file I sent), marking the middle one with the mouse will behave > like I'm proposing, ie. the cursor does not jump to the first or the > third displayed equation, but to the end of the middle. Yes. But in the outside world there is no way to select two chars in adjacent rows (like vi's "block mode" C-v). The situation _is_ different there. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On Sat, Apr 13, 2002 at 05:32:05PM +0200, Jean-Marc Lasgouttes wrote: But I have always known that everything is easy for you andre'... Surely not. Unless you use some unsual definition of 'always' ;-} Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On Sat, Apr 13, 2002 at 05:32:05PM +0200, Jean-Marc Lasgouttes wrote: > But I have always known that everything is easy for you andre'... Surely not. Unless you use some unsual definition of 'always' ;-} Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes Andre wrote: This is definitely annoying. Andre But easy to fix... But I have always known that everything is easy for you andre'... JMarc
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes Andre> wrote: >> This is definitely annoying. Andre> But easy to fix... But I have always known that everything is easy for you andre'... JMarc
Re: small mathed annoyance
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Another problem. With the attachaed file, the macros do not Jean-Marc redisplay correctly when you do pageup/down. I have also Jean-Marc seen cases where the contents of the macro got drawn Jean-Marc outside of the purple box (I'll have to reproduce it). Another way to look at the same problem: open user guide, go to section 5.5 (macros) and move a bit the scrollbar when you have a macro definition visible. Then look how the macros redraw themselves ouside of their purple box... This is definitely annoying. JMarc
Re: small mathed annoyance
On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes wrote: This is definitely annoying. But easy to fix... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Another problem. With the attachaed file, the macros do not Jean-Marc> redisplay correctly when you do pageup/down. I have also Jean-Marc> seen cases where the contents of the macro got drawn Jean-Marc> outside of the purple box (I'll have to reproduce it). Another way to look at the same problem: open user guide, go to section 5.5 (macros) and move a bit the scrollbar when you have a macro definition visible. Then look how the macros redraw themselves ouside of their purple box... This is definitely annoying. JMarc
Re: small mathed annoyance
On Fri, Apr 12, 2002 at 05:54:35PM +0200, Jean-Marc Lasgouttes wrote: > This is definitely annoying. But easy to fix... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Wed, Apr 10, 2002 at 05:53:25PM +0200, Jean-Marc Lasgouttes
Andre wrote:
This is not exactly what I had in mind, since for an unknown macro
(say \foo), I'd still want automatic instertion of braces.
Fell free to tell me that you don't want to fix that :)
Andre I don't want to fix that.
OK.
Andre PS: BTW how often do you use \macrowithoutarg{ ?
This is not the problem I had in mind. Assume there is a macros \foo
which takes an argument and which for some reason is not known to
mathed. When I type \foo{, I'd like to have the red braces. But
obviously, if I type, say, \sqrt{, I do not expect to have the braces,
since they are already provided by mathed.
Anyway, I thought about a different thing this morning (for later :).
In mathed you have some macros which only have a scope of one
character (like font changes), while most of them create a box, from
which you have to exit later. The (La)TeX behaviour is different: by
default, arguments are only one token, unless you add explicit braces
(add a box, in mathed terms). Why couldn't mathed have the same
behaviour? This makes simple formulas much easier to enter (a_i+b_i
vs. a_ispace+b_ispace) and would probably be intuitive to use. If
you want to have a longer subscript you can add a box, for example
with a lfun bound to (surprise!) the key {.
Does it make sense?
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:29:52AM +0200, Jean-Marc Lasgouttes wrote:
This is not the problem I had in mind. Assume there is a macros \foo
which takes an argument and which for some reason is not known to
mathed. When I type \foo{, I'd like to have the red braces. But
obviously, if I type, say, \sqrt{, I do not expect to have the braces,
since they are already provided by mathed.
I have a strong feeling that mathed will get more aware of macro arguments
during the 1.3 series and I think we might 'fix' this then. Consider filing
a feature request on bugzilla.
Anyway, I thought about a different thing this morning (for later :).
In mathed you have some macros which only have a scope of one
character (like font changes), while most of them create a box, from
which you have to exit later. The (La)TeX behaviour is different: by
default, arguments are only one token, unless you add explicit braces
(add a box, in mathed terms). Why couldn't mathed have the same
behaviour? This makes simple formulas much easier to enter (a_i+b_i
vs. a_ispace+b_ispace) and would probably be intuitive to use. If
you want to have a longer subscript you can add a box, for example
with a lfun bound to (surprise!) the key {.
Does it make sense?
Yes, but I don't think I want implement this. We would need a 'stateful
cursor' again to distiguish between '{' pressed or not, and editing
probably would get a mess again. How should editing work when you want to
change a_i to a_{ij}?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:29:52AM +0200, Jean-Marc Lasgouttes wrote:
Anyway, I thought about a different thing this morning (for later :).
In mathed you have some macros which only have a scope of one
character (like font changes), while most of them create a box, from
which you have to exit later. The (La)TeX behaviour is different: by
default, arguments are only one token, unless you add explicit braces
(add a box, in mathed terms). Why couldn't mathed have the same
behaviour? This makes simple formulas much easier to enter (a_i+b_i
vs. a_ispace+b_ispace) and would probably be intuitive to use. If
you want to have a longer subscript you can add a box, for example
with a lfun bound to (surprise!) the key {.
Does it make sense?
I like the sound of that.
Jules
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
Yes, but I don't think I want implement this. We would need a 'stateful
cursor' again to distiguish between '{' pressed or not, and editing
probably would get a mess again. How should editing work when you want to
change a_i to a_{ij}?
No you don't. If '{' is not pressed, the cursor is in a 'single char
subscript'. If '{' is pressed, the cursor is in a full blown box math
(inset). So the cursor's state is expressed by where it is?
Jules
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 09:51:03AM +0100, Jules Bean wrote:
Yes, but I don't think I want implement this. We would need a 'stateful
cursor' again to distiguish between '{' pressed or not, and editing
probably would get a mess again. How should editing work when you want to
change a_i to a_{ij}?
No you don't. If '{' is not pressed, the cursor is in a 'single char
subscript'. If '{' is pressed, the cursor is in a full blown box math
(inset).
[For the record: Everything in math is an 'inset', the boxes are 'cells' of
a 'nestinset' which is a special type of 'inset' which can have, well,
'nested cells']
So the cursor's state is expressed by where it is?
This would mean some extra inset for 'one char superscripts'?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On 11-Apr-2002 Jules Bean wrote:
On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
Yes, but I don't think I want implement this. We would need a 'stateful
cursor' again to distiguish between '{' pressed or not, and editing
probably would get a mess again. How should editing work when you want to
change a_i to a_{ij}?
No you don't. If '{' is not pressed, the cursor is in a 'single char
subscript'. If '{' is pressed, the cursor is in a full blown box math
(inset). So the cursor's state is expressed by where it is?
Yes but he's still right how would you edit when in single mode? We would
have to introduce a lot of code just for this case as you cannot simply add
a box before the i and where are you supposed to press '{' in that case?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Magic is always the best solution -- especially reliable magic.
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Yes, but I don't think I want implement this. We would need a
Andre 'stateful cursor' again to distiguish between '{' pressed or
Andre not, and editing probably would get a mess again.
No, an argument would be a single inset , which can be either a
single token (character, anything that make sense) or a `box inset'. A
`box inset' is an inset which contains a string of math insets.
Andre How should editing work when you want to change a_i to a_{ij}?
Using your award-winning (and patent pending) method of selecting the
'i' and using math-box-insert, which would create a box with i in it.
Note that I am not sure that this is better in all respects (and
unfortunately one has to implement it to find out), but it looks
interesting to me. And it gets you much closer to what TeX does.
JMarc
Re: small mathed annoyance
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 11-Apr-2002 Jules Bean wrote:
On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
Yes, but I don't think I want implement this. We would need a
'stateful cursor' again to distiguish between '{' pressed or not,
and editing probably would get a mess again. How should editing
work when you want to change a_i to a_{ij}?
No you don't. If '{' is not pressed, the cursor is in a 'single
char subscript'. If '{' is pressed, the cursor is in a full blown
box math (inset). So the cursor's state is expressed by where it
is?
Juergen Yes but he's still right how would you edit when in single
Juergen mode? We would have to introduce a lot of code just for this
Juergen case as you cannot simply add a box before the i and where
Juergen are you supposed to press '{' in that case?
How would you do that in latex? First you add {} around the single
char, then you add other chars. You can just do the same here.
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 11:30:51AM +0200, Jean-Marc Lasgouttes wrote:
Andre How should editing work when you want to change a_i to a_{ij}?
Using your award-winning (and patent pending) method of selecting the
'i' and using math-box-insert, which would create a box with i in it.
Note that I am not sure that this is better in all respects (and
unfortunately one has to implement it to find out),
I certainly would have a look at it if you came up with a reference
implementation.
but it looks interesting to me. And it gets you much closer to what TeX
does.
Indeed. But I can't see doing it easyly and consistently.
What about \frac? Do I need to have four insets for this then?
\frac12
\frac{11}2
\frac1{22}
\frac{11}{22}
The saved ' ' key press durcing input does not really seem worth the
trouble of the additional complexity.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre I certainly would have a look at it if you came up with a
Andre reference implementation.
I knew this was eventually coming...
Andre What about \frac? Do I need to have four insets for this then?
Andre \frac12 \frac{11}2 \frac1{22} \frac{11}{22}
No. Let me rephrase it: a macro argument is a math inset. A math inset
can be any normal inset (for example a single character or a\frac, as
in %a_\frac{a}{b}$, which latex understands perfectly), but it can be
a 'box inset', which holds a string of insets and outputs them enclosed
in braces.
Andre The saved ' ' key press durcing input does not really seem
Andre worth the trouble of the additional complexity.
I think it is actually simpler, since a macro does not need to know
what are their arguments: they are just single insets.
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 12:06:37PM +0200, Jean-Marc Lasgouttes wrote:
No. Let me rephrase it: a macro argument is a math inset. A math inset
can be any normal inset (for example a single character or a\frac, as
in %a_\frac{a}{b}$, which latex understands perfectly), but it can be
a 'box inset', which holds a string of insets and outputs them enclosed
in braces.
Ok. Currently we have a 'MathArray' which basically is your 'box inset'
and can hold any number of 'MathAtoms' (which are a sort of smart pointers
to other insets)
You suggest using instead some polymorphic structure that can be either of
a 'MathArray' as we have now, and a single 'MathAtom'.
Is that what you mean?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Ok. Currently we have a 'MathArray' which basically is your Andre 'box inset' and can hold any number of 'MathAtoms' (which are a Andre sort of smart pointers to other insets) Andre You suggest using instead some polymorphic structure that can Andre be either of a 'MathArray' as we have now, and a single Andre 'MathAtom'. Andre Is that what you mean? Yes, probably. This amounts to saying that a matharray is actually a kind of mathatom. JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 12:20:08PM +0200, Jean-Marc Lasgouttes wrote:
Yes, probably. This amounts to saying that a matharray is actually a
kind of mathatom.
Guess what. We already have MathBraceInset, which are MathNestInsets with a
single cell (MathArray) that get written to LaTeX as '{', contents, '}'.
So we could reformulate this as:
Currently:
MathFracInset == MathNestInset with two MathArrays
MathArray == vectorMathAtom
MathAtom == smartpointerMathInset
Is this what you want:
MathFracInset == MathNestInset with two MathAtoms
MathAtom == smartpointerMathInset
MathBraceInset == some special Mathinset == vectorMathAtom
?
This would look feasible. And it would actually memory usage a bit since a
MathAtom is smaller than a MathArray with one entry...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre So we could reformulate this as: Andre Currently: Andre MathFracInset == MathNestInset with two MathArrays Andre MathArray == vectorMathAtom MathAtom == Andre smartpointerMathInset Andre Is this what you want: Andre MathFracInset == MathNestInset with two MathAtoms MathAtom Andre == smartpointerMathInset MathBraceInset == some special Andre Mathinset == vectorMathAtom Andre ? Yes, something like this. Andre This would look feasible. And it would actually memory usage a Andre bit since a MathAtom is smaller than a MathArray with one Andre entry... The problem first is to know whether it is desirable :) I cannot guess what all the implications of this might be. But I think that with current mathed, one has to use space much too often for fast typing. JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 01:46:12PM +0200, Jean-Marc Lasgouttes wrote: Andre This would look feasible. And it would actually memory usage a Andre bit since a MathAtom is smaller than a MathArray with one Andre entry... The problem first is to know whether it is desirable :) I cannot guess what all the implications of this might be. Well... it's a fairly fundamental blow to the current architecture. Getting it compiled should be easy, however. The real problem will be to get editing and navigation working again, and quite a few people won't like it because it will be different... But I think that with current mathed, one has to use space much too often for fast typing. Maybe our usage patterns differ. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Well... it's a fairly fundamental blow to the current Andre architecture. Indeed. Andre Getting it compiled should be easy, however. The real problem Andre will be to get editing and navigation working again, and quite Andre a few people won't like it because it will be different... Agreed. I just had to share this bright idea with bright people :) But I think that with current mathed, one has to use space much too often for fast typing. Andre Maybe our usage patterns differ. Don't you use subscripts? JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 02:55:50PM +0200, Jean-Marc Lasgouttes wrote: Andre Maybe our usage patterns differ. Don't you use subscripts? Sometimes ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Wed, Apr 10, 2002 at 05:53:25PM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> This is not exactly what I had in mind, since for an unknown macro
>> (say \foo), I'd still want automatic instertion of braces.
>>
>> Fell free to tell me that you don't want to fix that :)
Andre> I don't want to fix that.
OK.
Andre> PS: BTW how often do you use \macrowithoutarg{ ?
This is not the problem I had in mind. Assume there is a macros \foo
which takes an argument and which for some reason is not known to
mathed. When I type \foo{, I'd like to have the red braces. But
obviously, if I type, say, \sqrt{, I do not expect to have the braces,
since they are already provided by mathed.
Anyway, I thought about a different thing this morning (for later :).
In mathed you have some macros which only have a scope of one
character (like font changes), while most of them create a box, from
which you have to exit later. The (La)TeX behaviour is different: by
default, arguments are only one token, unless you add explicit braces
(add a box, in mathed terms). Why couldn't mathed have the same
behaviour? This makes simple formulas much easier to enter (a_i+b_i
vs. a_i+b_i) and would probably be intuitive to use. If
you want to have a longer subscript you can add a box, for example
with a lfun bound to (surprise!) the key {.
Does it make sense?
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:29:52AM +0200, Jean-Marc Lasgouttes wrote:
> This is not the problem I had in mind. Assume there is a macros \foo
> which takes an argument and which for some reason is not known to
> mathed. When I type \foo{, I'd like to have the red braces. But
> obviously, if I type, say, \sqrt{, I do not expect to have the braces,
> since they are already provided by mathed.
I have a strong feeling that mathed will get more aware of macro arguments
during the 1.3 series and I think we might 'fix' this then. Consider filing
a feature request on bugzilla.
> Anyway, I thought about a different thing this morning (for later :).
> In mathed you have some macros which only have a scope of one
> character (like font changes), while most of them create a box, from
> which you have to exit later. The (La)TeX behaviour is different: by
> default, arguments are only one token, unless you add explicit braces
> (add a box, in mathed terms). Why couldn't mathed have the same
> behaviour? This makes simple formulas much easier to enter (a_i+b_i
> vs. a_i+b_i) and would probably be intuitive to use. If
> you want to have a longer subscript you can add a box, for example
> with a lfun bound to (surprise!) the key {.
>
> Does it make sense?
Yes, but I don't think I want implement this. We would need a 'stateful
cursor' again to distiguish between '{' pressed or not, and editing
probably would get a mess again. How should editing work when you want to
change a_i to a_{ij}?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:29:52AM +0200, Jean-Marc Lasgouttes wrote:
> Anyway, I thought about a different thing this morning (for later :).
> In mathed you have some macros which only have a scope of one
> character (like font changes), while most of them create a box, from
> which you have to exit later. The (La)TeX behaviour is different: by
> default, arguments are only one token, unless you add explicit braces
> (add a box, in mathed terms). Why couldn't mathed have the same
> behaviour? This makes simple formulas much easier to enter (a_i+b_i
> vs. a_i+b_i) and would probably be intuitive to use. If
> you want to have a longer subscript you can add a box, for example
> with a lfun bound to (surprise!) the key {.
>
> Does it make sense?
I like the sound of that.
Jules
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
> Yes, but I don't think I want implement this. We would need a 'stateful
> cursor' again to distiguish between '{' pressed or not, and editing
> probably would get a mess again. How should editing work when you want to
> change a_i to a_{ij}?
No you don't. If '{' is not pressed, the cursor is in a 'single char
subscript'. If '{' is pressed, the cursor is in a full blown box math
(inset). So the cursor's state is expressed by where it is?
Jules
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 09:51:03AM +0100, Jules Bean wrote:
> > Yes, but I don't think I want implement this. We would need a 'stateful
> > cursor' again to distiguish between '{' pressed or not, and editing
> > probably would get a mess again. How should editing work when you want to
> > change a_i to a_{ij}?
>
> No you don't. If '{' is not pressed, the cursor is in a 'single char
> subscript'. If '{' is pressed, the cursor is in a full blown box math
> (inset).
[For the record: Everything in math is an 'inset', the boxes are 'cells' of
a 'nestinset' which is a special type of 'inset' which can have, well,
'nested cells']
> So the cursor's state is expressed by where it is?
This would mean some extra inset for 'one char superscripts'?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
On 11-Apr-2002 Jules Bean wrote:
> On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
>> Yes, but I don't think I want implement this. We would need a 'stateful
>> cursor' again to distiguish between '{' pressed or not, and editing
>> probably would get a mess again. How should editing work when you want to
>> change a_i to a_{ij}?
>
> No you don't. If '{' is not pressed, the cursor is in a 'single char
> subscript'. If '{' is pressed, the cursor is in a full blown box math
> (inset). So the cursor's state is expressed by where it is?
Yes but he's still right how would you "edit" when in single mode? We would
have to introduce a lot of code just for this case as you cannot simply add
a box before the i and where are you supposed to press '{' in that case?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Magic is always the best solution -- especially reliable magic.
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Yes, but I don't think I want implement this. We would need a
Andre> 'stateful cursor' again to distiguish between '{' pressed or
Andre> not, and editing probably would get a mess again.
No, an argument would be a single inset , which can be either a
single token (character, anything that make sense) or a `box inset'. A
`box inset' is an inset which contains a string of math insets.
Andre> How should editing work when you want to change a_i to a_{ij}?
Using your award-winning (and patent pending) method of selecting the
'i' and using math-box-insert, which would create a box with i in it.
Note that I am not sure that this is better in all respects (and
unfortunately one has to implement it to find out), but it looks
interesting to me. And it gets you much closer to what TeX does.
JMarc
Re: small mathed annoyance
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 11-Apr-2002 Jules Bean wrote:
>> On Thu, Apr 11, 2002 at 10:46:38AM +0200, Andre Poenitz wrote:
>>> Yes, but I don't think I want implement this. We would need a
>>> 'stateful cursor' again to distiguish between '{' pressed or not,
>>> and editing probably would get a mess again. How should editing
>>> work when you want to change a_i to a_{ij}?
>> No you don't. If '{' is not pressed, the cursor is in a 'single
>> char subscript'. If '{' is pressed, the cursor is in a full blown
>> box math (inset). So the cursor's state is expressed by where it
>> is?
Juergen> Yes but he's still right how would you "edit" when in single
Juergen> mode? We would have to introduce a lot of code just for this
Juergen> case as you cannot simply add a box before the i and where
Juergen> are you supposed to press '{' in that case?
How would you do that in latex? First you add {} around the single
char, then you add other chars. You can just do the same here.
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 11:30:51AM +0200, Jean-Marc Lasgouttes wrote:
> Andre> How should editing work when you want to change a_i to a_{ij}?
>
> Using your award-winning (and patent pending) method of selecting the
> 'i' and using math-box-insert, which would create a box with i in it.
>
> Note that I am not sure that this is better in all respects (and
> unfortunately one has to implement it to find out),
I certainly would have a look at it if you came up with a reference
implementation.
> but it looks interesting to me. And it gets you much closer to what TeX
> does.
Indeed. But I can't see doing it easyly and consistently.
What about \frac? Do I need to have four insets for this then?
\frac12
\frac{11}2
\frac1{22}
\frac{11}{22}
The saved ' ' key press durcing input does not really seem worth the
trouble of the additional complexity.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I certainly would have a look at it if you came up with a
Andre> reference implementation.
I knew this was eventually coming...
Andre> What about \frac? Do I need to have four insets for this then?
Andre> \frac12 \frac{11}2 \frac1{22} \frac{11}{22}
No. Let me rephrase it: a macro argument is a math inset. A math inset
can be any normal inset (for example a single character or a\frac, as
in %a_\frac{a}{b}$, which latex understands perfectly), but it can be
a 'box inset', which holds a string of insets and outputs them enclosed
in braces.
Andre> The saved ' ' key press durcing input does not really seem
Andre> worth the trouble of the additional complexity.
I think it is actually simpler, since a macro does not need to know
what are their arguments: they are just single insets.
JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 12:06:37PM +0200, Jean-Marc Lasgouttes wrote:
> No. Let me rephrase it: a macro argument is a math inset. A math inset
> can be any normal inset (for example a single character or a\frac, as
> in %a_\frac{a}{b}$, which latex understands perfectly), but it can be
> a 'box inset', which holds a string of insets and outputs them enclosed
> in braces.
Ok. Currently we have a 'MathArray' which basically is your 'box inset'
and can hold any number of 'MathAtoms' (which are a sort of smart pointers
to other insets)
You suggest using instead some polymorphic structure that can be either of
a 'MathArray' as we have now, and a single 'MathAtom'.
Is that what you mean?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Ok. Currently we have a 'MathArray' which basically is your Andre> 'box inset' and can hold any number of 'MathAtoms' (which are a Andre> sort of smart pointers to other insets) Andre> You suggest using instead some polymorphic structure that can Andre> be either of a 'MathArray' as we have now, and a single Andre> 'MathAtom'. Andre> Is that what you mean? Yes, probably. This amounts to saying that a matharray is actually a kind of mathatom. JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 12:20:08PM +0200, Jean-Marc Lasgouttes wrote:
> Yes, probably. This amounts to saying that a matharray is actually a
> kind of mathatom.
Guess what. We already have MathBraceInset, which are MathNestInsets with a
single cell (MathArray) that get written to LaTeX as '{', contents, '}'.
So we could reformulate this as:
Currently:
MathFracInset == MathNestInset with two MathArrays
MathArray == vector
MathAtom == smartpointer
Is this what you want:
MathFracInset == MathNestInset with two MathAtoms
MathAtom == smartpointer
MathBraceInset == some special Mathinset == vector
?
This would look feasible. And it would actually memory usage a bit since a
MathAtom is smaller than a MathArray with one entry...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> So we could reformulate this as: Andre> Currently: Andre> MathFracInset == MathNestInset with two MathArrays Andre> MathArray == vector MathAtom == Andre> smartpointer Andre> Is this what you want: Andre> MathFracInset == MathNestInset with two MathAtoms MathAtom Andre> == smartpointer MathBraceInset == some special Andre> Mathinset == vector Andre> ? Yes, something like this. Andre> This would look feasible. And it would actually memory usage a Andre> bit since a MathAtom is smaller than a MathArray with one Andre> entry... The problem first is to know whether it is desirable :) I cannot guess what all the implications of this might be. But I think that with current mathed, one has to use much too often for fast typing. JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 01:46:12PM +0200, Jean-Marc Lasgouttes wrote: > Andre> This would look feasible. And it would actually memory usage a > Andre> bit since a MathAtom is smaller than a MathArray with one > Andre> entry... > > The problem first is to know whether it is desirable :) I cannot guess > what all the implications of this might be. Well... it's a fairly fundamental blow to the current architecture. Getting it compiled should be easy, however. The real problem will be to get editing and navigation working again, and quite a few people won't like it because it will be different... > But I think that with current mathed, one has to use much too > often for fast typing. Maybe our usage patterns differ. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Well... it's a fairly fundamental blow to the current Andre> architecture. Indeed. Andre> Getting it compiled should be easy, however. The real problem Andre> will be to get editing and navigation working again, and quite Andre> a few people won't like it because it will be different... Agreed. I just had to share this bright idea with bright people :) >> But I think that with current mathed, one has to use much >> too often for fast typing. Andre> Maybe our usage patterns differ. Don't you use subscripts? JMarc
Re: small mathed annoyance
On Thu, Apr 11, 2002 at 02:55:50PM +0200, Jean-Marc Lasgouttes wrote: > Andre> Maybe our usage patterns differ. > > Don't you use subscripts? Sometimes ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
small mathed annoyance
If I use mathed to type formulas as if I was typing latex and find
myself typing \frac{ to begin fractions. This inserts unwanted red {}
in the numerator. Would it be possible not to insert these {} if the
macro is (1) known to mathed and (2) known to take at least one
argument?
Or maybe I should just change my typing habits.
JMarc
Re: small mathed annoyance
On Wed, Apr 10, 2002 at 02:02:48PM +0200, Jean-Marc Lasgouttes wrote:
If I use mathed to type formulas as if I was typing latex and find
myself typing \frac{ to begin fractions. This inserts unwanted red {}
in the numerator. Would it be possible not to insert these {} if the
macro is (1) known to mathed and (2) known to take at least one
argument?
Add || c == '{' to line 1463 in math_cursor.C and look if it works
and does not break anything else.
The {} handling is very fragile, too fragile actually to get it right.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Add || c == '{' to line 1463 in math_cursor.C and look if
Andre it works and does not break anything else.
Andre The {} handling is very fragile, too fragile actually to get it
Andre right.
I'll try it.
Another problem. With the attachaed file, the macros do not redisplay
correctly when you do pageup/down. I have also seen cases where the
contents of the macro got drawn outside of the purple box (I'll have
to reproduce it).
JMarc
bug.lyx
Description: Binary data
Re: small mathed annoyance
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Add || c == '{' to line 1463 in math_cursor.C and look if
Andre it works and does not break anything else.
Andre The {} handling is very fragile, too fragile actually to get it
Andre right.
This is not exactly what I had in mind, since for an unknown macro
(say \foo), I'd still want automatic instertion of braces.
Fell free to tell me that you don't want to fix that :)
JMarc
Re: small mathed annoyance
On Wed, Apr 10, 2002 at 05:53:25PM +0200, Jean-Marc Lasgouttes wrote:
This is not exactly what I had in mind, since for an unknown macro
(say \foo), I'd still want automatic instertion of braces.
Fell free to tell me that you don't want to fix that :)
I don't want to fix that.
Andre'
PS: BTW how often do you use \macrowithoutarg{ ?
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
small mathed annoyance
If I use mathed to type formulas as if I was typing latex and find
myself typing \frac{ to begin fractions. This inserts unwanted red {}
in the numerator. Would it be possible not to insert these {} if the
macro is (1) known to mathed and (2) known to take at least one
argument?
Or maybe I should just change my typing habits.
JMarc
Re: small mathed annoyance
On Wed, Apr 10, 2002 at 02:02:48PM +0200, Jean-Marc Lasgouttes wrote:
> If I use mathed to type formulas as if I was typing latex and find
> myself typing \frac{ to begin fractions. This inserts unwanted red {}
> in the numerator. Would it be possible not to insert these {} if the
> macro is (1) known to mathed and (2) known to take at least one
> argument?
Add " || c == '{' " to line 1463 in math_cursor.C and look if it works
and does not break anything else.
The {} handling is very fragile, too fragile actually to get it right.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Add " || c == '{' " to line 1463 in math_cursor.C and look if
Andre> it works and does not break anything else.
Andre> The {} handling is very fragile, too fragile actually to get it
Andre> right.
I'll try it.
Another problem. With the attachaed file, the macros do not redisplay
correctly when you do pageup/down. I have also seen cases where the
contents of the macro got drawn outside of the purple box (I'll have
to reproduce it).
JMarc
bug.lyx
Description: Binary data
Re: small mathed annoyance
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Add " || c == '{' " to line 1463 in math_cursor.C and look if
Andre> it works and does not break anything else.
Andre> The {} handling is very fragile, too fragile actually to get it
Andre> right.
This is not exactly what I had in mind, since for an unknown macro
(say \foo), I'd still want automatic instertion of braces.
Fell free to tell me that you don't want to fix that :)
JMarc
Re: small mathed annoyance
On Wed, Apr 10, 2002 at 05:53:25PM +0200, Jean-Marc Lasgouttes wrote:
> This is not exactly what I had in mind, since for an unknown macro
> (say \foo), I'd still want automatic instertion of braces.
>
> Fell free to tell me that you don't want to fix that :)
I don't want to fix that.
Andre'
PS: BTW how often do you use \macrowithoutarg{ ?
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
