> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Certainly (although I did not try to actually edit a document with
>> the new scheme).
Andre> Simply try it.
I did try it. What I do not know is how it would feel in `real life'.
>> And what about using an explicit command to open t
> Certainly (although I did not try to actually edit a document with the
> new scheme).
Simply try it.
> And what about using an explicit command to open the macro inset?
You mean "ordinary cursor movement" jump over the unopened macro in one
step and some key combination explicitly opens it?
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Personally, I'd like to have some visual feedback (a) that I am
Andre> editing macro arguments at all (b) the name of the macro I am
Andre> editing
Andre> (a) is easy with another box color or so, (b) could be done
Andre> with the
> Andre> This would surely be possible, but some this means "hiding"
> Andre> some of the macro's context. I don't know whether this is a
> Andre> good idea.
>
> Is it possible to do you "new style" editing only when there is a
> repeated argument in the definition?
Well... we could try that. Th
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> - I'm afraid that the expansion of macro instances when editing
>> them is a little bit annoying. I wonder if it possible to draw the
>> "expansion box", without changing anything else in the display. In
>> other words, the "expansion
> I've found another bug:
> The size of big operators in display equation is like in inline equation and
> not bigger.
> [...]
Ok. I had a couple of hours sleep over it.
Mathed is currently broken and unusable for serious work. I have stated
this several times already.
Mathed is after applicati
> I've found another bug:
> The size of big operators in display equation is like in inline equation and
> not bigger.
> Also, when you enter the limits for big operator in display equation, they
> appear like in inline equation.
Ok, I see. You won't let me go away with simply saying "font sizes
I've found another bug:
The size of big operators in display equation is like in inline equation and
not bigger.
Also, when you enter the limits for big operator in display equation, they
appear like in inline equation.
-- n
\
/
-- i=1
instead of
n
-
\
\
/
/
-
i=1
> I don't think that this feature is hard to implement.
> You just need to be able to cut from the current position to the end of the
> cell. How hard is that ?
I need to access the math cursor, which is not aware of multi cell
"environments" per se. This was no problem in the past since the mult
On Mon, May 28, 2001 at 06:00:29PM +0200, Andre Poenitz wrote:
> >
> > - C-tab doesn't do anything.
> > It should move the contents of current cell (which is to the right of the
> > cursor) to the next cell.
>
> I hope you don't have more of these functions unknown to me in your
> sleeves.
>
>
> When you create an eqnarray, the 1st row is unnumbered, but the 2nd row is
> numbered. Also, when new rows are added, they are numbered.
>
> Again, when saving an unnumbered eqnarray (i.e. eqnarray*), after reading the
> file, the 1st row is unnumbered, while all other rows are numbered.
Fixed
On Mon, May 28, 2001 at 03:28:13PM +0200, Andre Poenitz wrote:
> > - Creating a displayed equation creates a numbered equation. The default
> > should be unnumbered.
> Changed back to old behaviour, i.e. "fixed".
When you create an eqnarray, the 1st row is unnumbered, but the 2nd row is
number
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I think this patch could go into CVS as-is.
|
| [Well, maybe someone should check first that I added all new files]
So I'll wait a bit, in case somebody yells.
If I hear nothing I'll commit the patch.
--
Lgb
13 matches
Mail list logo
