On Tue, Dec 09, 2003 at 10:31:51AM +0100, Andre Poenitz spake thusly:
> > BTW should we have symmetric behaviour? I.e. pressing 'delete' on the
> > inside of the right of a parentheses pair would 'melt' the pair. But
> > it seems this is already bound...
>
> bound? What?
To deleting a matrix ro
On Tue, Dec 09, 2003 at 11:04:41AM +0200, Martin Vermeer wrote:
> On Mon, Dec 08, 2003 at 11:40:48AM +0100, Andre Poenitz spake thusly:
>
> > Index: math_cursor.C
> > ===
> > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_
On Mon, Dec 08, 2003 at 11:40:48AM +0100, Andre Poenitz spake thusly:
> Index: math_cursor.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_cursor.C,v
> retrieving revision 1.368
> diff -u -p -r1.368 math_cursor.C
On Mon, 8 Dec 2003, Andre Poenitz wrote:
> On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote:
> > > Straight-forward. Five lines at most.
> >
> > Which five lines?
> >
> > :-)
>
> Attached.
>
> Actually, I even think this feature is usable.
Not bad... I think this should be appli
On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote:
> > Straight-forward. Five lines at most.
>
> Which five lines?
>
> :-)
Attached.
Actually, I even think this feature is usable.
Andre'
? .math_cursor.C.swp
? 1.diff
? cursor.diff
Index: math_cursor.C
=
On Mon, Dec 08, 2003 at 09:46:16AM +0100, Andre Poenitz spake thusly:
> > One could in the above situation make the first backspace invoke
> > selection of the previous bracketed expression. I don't know how hard
> > that is to implement.
>
> Straight-forward. Five lines at most.
Which five lin
On Sat, Dec 06, 2003 at 10:59:30AM +0200, Martin Vermeer wrote:
> This is actually not a bad idea. But we sort-of have this now already.
> In MathEd, I never delete anything but single characters straightaway.
> I don't dare to :-( If I want to delete a bracketed expression etc., I
> always select
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström wrote:
> I agree with Helge here, and it reminded me of a behaviour that's
> sometimes annoying in mathed. It happens quite often that I delete the
> previous 'box' without intending to when using the backspace key. An
> example (ju
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström spake thusly:
> In case that was unclear, here's an example:
>
> a^2+\textrm{aFunction}+2|
>
> pressing backspace gives
>
> a^2+\textrm{aFunction}+|
>
> backspace again...
>
> a^2+\textrm{aFunction}|
>
> now w
On Fri, 5 Dec 2003, Helge Hafting wrote:
> Andre Poenitz wrote:
> > On Thu, Dec 04, 2003 at 11:43:16AM +0100, Helge Hafting wrote:
> I can't even unapply a change of some text to bold in mathed without
> running round the houses.
> >>>What's wrong with ?
> >>
> >>People don't think of t
> On Wed, Apr 18, 2001 at 10:18:30AM +0200, Andre Poenitz wrote:
> > > 2. The cursor is broken when it is inside a macro instance.
>
> When you move into a macro, the cursor doesn't appear where it should.
> In fact, it is drawn completely outside the math inset (and sometimes the
> screen scroll
On Wed, Apr 18, 2001 at 10:18:30AM +0200, Andre Poenitz wrote:
> > 2. The cursor is broken when it is inside a macro instance.
>
> How?
When you move into a macro, the cursor doesn't appear where it should.
In fact, it is drawn completely outside the math inset (and sometimes the
screen scroll t
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Do I understand it right that arrays for mated:
>>
>> 1. Do not have visual (border)lines
Andre> I have not seen any so far...
Well, if you look at the deinition of the array environment, it is the
same thing as a tabular, except th
> Do I understand it right that arrays for mated:
>
> 1. Do not have visual (border)lines
I have not seen any so far...
Moreover, multiline math is conceptually somewhat simpler than "real
tables" since it does not need to handle multicolumn cells.
> 2. Instead of having a InsetText they woul
> If you are going to rewrite array support, would it make sense to
> share code with the tabular inset? At latex level, these are the same
> objects, after all. I understand that there will be many problem, but
> this is the "ideal" solution, after all.
In theory yes.
In practice it'd probably
On 20-Apr-2001 Jean-Marc Lasgouttes wrote:
> If you are going to rewrite array support, would it make sense to
> share code with the tabular inset? At latex level, these are the same
> objects, after all. I understand that there will be many problem, but
> this is the "ideal" solution, after all
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I think a more suitable implementation of matrices and array
Andre> would involve a one-dimesional array (i.e. std::vector) of "row
Andre> structures", each holding another one-dimensional array of
Andre> "entries", an optional num
> On Tue, Apr 17, 2001 at 06:00:58PM +0200, Andre Poenitz wrote:
> > PS: Would be nice to get some more feedback to the "macro monster patch",
> > otherwise I'll have a hard time to force-feed this down Lars's throat ;-}
>
> I had few problems with your patch:
> 1. In macro instances, the argumen
On Tue, Apr 17, 2001 at 06:00:58PM +0200, Andre Poenitz wrote:
> PS: Would be nice to get some more feedback to the "macro monster patch",
> otherwise I'll have a hard time to force-feed this down Lars's throat ;-}
I had few problems with your patch:
1. In macro instances, the argument where not
A short request for comments to prepare the step after the macro stuff:
Currently \eqnarray and math tables are internally stored as a single
inset with "embedded" TABs and CRs to mimic "next cell in a row" and "next
row". In parallel to this structure there exists another structure that
handle
20 matches
Mail list logo
