Andre == Andre Poenitz [EMAIL PROTECTED] writes:
OK, here is my next try. I kind of like the code now, so I'd
really want to commit it and be done with this bug?
Andre It looks ok. No more objections from my side.
It seems you were right to complain about the code and make think more
about
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> OK, here is my next try. I kind of like the code now, so I'd
>> really want to commit it and be done with this bug?
Andre> It looks ok. No more objections from my side.
It seems you were right to complain about the code and make
On Tue, 2006-01-10 at 12:53 +0100, Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre shouldn't it?
OK, here is my next try. I kind of like the code now, so I'd really
want to commit it and
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin On Tue, 2006-01-10 at 12:53 +0100, Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz
[EMAIL PROTECTED] writes:
Andre prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre shouldn't it?
OK, here is my next try. I kind
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg I could not get it to crash, but I found another related
Georg problem (which does also occur without the patch):
Georg \fracESC
Georg results in the text \frac in red, it is not recognized as a
Georg fraction as it is in 1.3.x
This can be
Am Mittwoch, 11. Januar 2006 17:45 schrieb Jean-Marc Lasgouttes:
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg I could not get it to crash, but I found another related
Georg problem (which does also occur without the patch):
Georg \fracESC
Georg results in the text \frac in red,
On Tue, 2006-01-10 at 12:53 +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> prevAtom(). Or maybe nextAtom(). Should be near the cursor,
> Andre> shouldn't it?
>
> OK, here is my next try. I kind of like the code now, so I'd really
> want
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Tue, 2006-01-10 at 12:53 +0100, Jean-Marc Lasgouttes wrote:
>> > "Andre" == Andre Poenitz
>> <[EMAIL PROTECTED]> writes:
>>
Andre> prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre> shouldn't it?
>> OK,
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I could not get it to crash, but I found another related
Georg> problem (which does also occur without the patch):
Georg> \frac
Georg> results in the text \frac in red, it is not recognized as a
Georg> fraction as it is in 1.3.x
Am Mittwoch, 11. Januar 2006 17:45 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> I could not get it to crash, but I found another related
> Georg> problem (which does also occur without the patch):
>
> Georg> \frac
>
> Georg> results in the
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre shouldn't it?
OK, here is my next try. I kind of like the code now, so I'd really
want to commit it and be done with this bug?
Can somebody test? It fixes a crash introduced
Am Dienstag, 10. Januar 2006 12:53 schrieb Jean-Marc Lasgouttes:
Andre == Andre Poenitz [EMAIL PROTECTED]
writes:
Andre prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre shouldn't it?
OK, here is my next try. I kind of like the code now, so I'd really
want to commit it
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> prevAtom(). Or maybe nextAtom(). Should be near the cursor,
Andre> shouldn't it?
OK, here is my next try. I kind of like the code now, so I'd really
want to commit it and be done with this bug?
Can somebody test? It fixes a crash
Am Dienstag, 10. Januar 2006 12:53 schrieb Jean-Marc Lasgouttes:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]>
writes:
>
> Andre> prevAtom(). Or maybe nextAtom(). Should be near the cursor,
> Andre> shouldn't it?
>
> OK, here is my next try. I kind of like the code now, so I'd really
>
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Can't you simply put the new stuff in a separate function? I
Andre always have a feeling that additional bool parameters do not
Andre improve readability, especially when the function in question
Andre basically looks like
Andre void
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Not really, because it is only in macroMathClose that I have
access to the object that has been created there. How would I
access the newly built \frac{}{} object otherwise?
Andre prevAtom(). Or maybe nextAtom(). Should be near the cursor,
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Can't you simply put the new stuff in a separate function? I
Andre> always have a feeling that additional bool parameters do not
Andre> improve readability, especially when the function in question
Andre> basically looks like
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Not really, because it is only in macroMathClose that I have
>> access to the object that has been created there. How would I
>> access the newly built \frac{}{} object otherwise?
Andre> prevAtom(). Or maybe nextAtom(). Should be
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
So, what do you propose? I guess I could keep mathMacroClose as it
was,
Andre Yes.
and put the cursor inside the new inset only when space was
pressed?
What about that one?
JMarc
Index: src/ChangeLog
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> So, what do you propose? I guess I could keep mathMacroClose as it
>> was,
Andre> Yes.
>> and put the cursor inside the new inset only when space was
>> pressed?
What about that one?
JMarc
Index: src/ChangeLog
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre What's the actual cursor positioning problem?
Andre I'd really like to get that fixed by direct calls.
The problem is that, when one types \fracspace, the fraction is
inserted, but the cursor is not in the first cell. So I looked at what
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> What's the actual cursor positioning problem?
Andre> I'd really like to get that fixed by direct calls.
The problem is that, when one types "\frac", the fraction is
inserted, but the cursor is not in the first cell. So I looked
Martin Vermeer wrote:
The following is perhaps lighter, and could be considered an alternative
if there are side effects. (But this may have such as well.)
BTW this is bug 2034: http://bugzilla.lyx.org/show_bug.cgi?id=2034
Georg
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin On Mon, Dec 19, 2005 at 05:39:42PM +0100, Jean-Marc Lasgouttes
Martin wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin ...
Martin Confirmed. This problem happens if you try to to type LaTeX
Martin directly. It works
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Martin Vermeer wrote:
The following is perhaps lighter, and could be considered an
alternative if there are side effects. (But this may have such as
well.)
Georg BTW this is bug 2034:
Georg http://bugzilla.lyx.org/show_bug.cgi?id=2034
On Tue, 2005-12-20 at 12:44 +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin On Mon, Dec 19, 2005 at 05:39:42PM +0100, Jean-Marc Lasgouttes
Martin wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin ...
Martin Confirmed. This
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Yes, I see. I think your patch is precisely the right one as
Martin this method is called whenever a macro has been typed in. And
Martin it is minimal.
Here is the alternative that does not use dispatch (I copied blindly
the code
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Alternatively, put this in a method and call that from both
Martin places.
Yes, but insert, plainInsert and niceInsert are already taken, I do
not have any new idea for a confusing name :)
I propose keep the dispatch and add a comment
Jean-Marc Lasgouttes wrote:
Martin Alternatively, put this in a method and call that from both
Martin places.
Yes, but insert, plainInsert and niceInsert are already taken, I do
not have any new idea for a confusing name :)
What about JMInsert ;-)
I propose keep the dispatch and add a
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg I have no time to try it now, but I like this solution.
OK, I applied it.
JMarc
Martin Vermeer wrote:
> The following is perhaps lighter, and could be considered an alternative
> if there are side effects. (But this may have such as well.)
BTW this is bug 2034: http://bugzilla.lyx.org/show_bug.cgi?id=2034
Georg
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Mon, Dec 19, 2005 at 05:39:42PM +0100, Jean-Marc Lasgouttes
Martin> wrote:
>> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> ...
Martin> Confirmed. This problem happens if you try to to type LaTeX
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Martin Vermeer wrote:
>> The following is perhaps lighter, and could be considered an
>> alternative if there are side effects. (But this may have such as
>> well.)
Georg> BTW this is bug 2034:
Georg>
On Tue, 2005-12-20 at 12:44 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Mon, Dec 19, 2005 at 05:39:42PM +0100, Jean-Marc Lasgouttes
> Martin> wrote:
> >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes, I see. I think your patch is precisely the right one as
Martin> this method is called whenever a macro has been typed in. And
Martin> it is minimal.
Here is the alternative that does not use dispatch (I copied blindly
the
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Alternatively, put this in a method and call that from both
Martin> places.
Yes, but insert, plainInsert and niceInsert are already taken, I do
not have any new idea for a confusing name :)
I propose keep the dispatch and add
Jean-Marc Lasgouttes wrote:
> Martin> Alternatively, put this in a method and call that from both
> Martin> places.
>
> Yes, but insert, plainInsert and niceInsert are already taken, I do
> not have any new idea for a confusing name :)
What about JMInsert ;-)
> I propose keep the dispatch and
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I have no time to try it now, but I like this solution.
OK, I applied it.
JMarc
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin On Mon, 2005-12-19 at 00:42 -0500, Grag wrote:
I noticed some difference between the behavior of the mathinset
that is inconsistent with lyx 1.3.x
For instance 1) enter math inset 2) \hat 3) \beta In lyx 1.3.x the
beta would be
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Mon, 2005-12-19 at 00:42 -0500, Grag wrote:
>> I noticed some difference between the behavior of the mathinset
>> that is inconsistent with lyx 1.3.x
>>
>> For instance 1) enter math inset 2) \hat 3) \beta In lyx 1.3.x the
40 matches
Mail list logo
