> "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 thin
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 te
> "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
Thi
> "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, h
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
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
> wa
> "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
> "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
> "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" == 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 "\frac", the fraction is
inserted, but the cursor is not in the first cell. So I looked at
> "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
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 a
> "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
> "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 c
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> .
> "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.
> "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
Mart
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, 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
>>
20 matches
Mail list logo
