IGNORE this one. It misses Abdel's point about the other stuff we do on
blink.
rh
Richard Heck wrote:
Attached. Pavel, if it works for you, go ahead and commit.
It should probably also go to branch. OK, Jurgen?
rh
Attached. Pavel, if it works for you, go ahead and commit.
It should probably also go to branch. OK, Jurgen?
rh
Index: frontends/qt4/GuiWorkArea.cpp
===
--- frontends/qt4/GuiWorkArea.cpp (revision 22743)
+++ frontends/qt4/GuiWorkA
Stefan Schimanski schrieb:
Will be away until Sunday/Monday. Feel free to commit it.
Abdel gave his OK too, so committed it for you:
http://www.lyx.org/trac/changeset/18799
regards Uwe
Stefan Schimanski wrote:
I also noticed this problem since a while. The patch seems obvious and
fixes the problems for me, so I give an OK.
Will be away until Sunday/Monday. Feel free to commit it.
You have my OK if you want to commit now ;-)
Abdel.
I also noticed this problem since a while. The patch seems obvious
and fixes the problems for me, so I give an OK.
Will be away until Sunday/Monday. Feel free to commit it.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
> Here is a patch for the following problem:
>
> Write something in a "Standard" layout paragraph. Change it into Title.
>
> The cursor will stay at the old position until the cursor blink
> interval is over
I also noticed this problem since a while. The patch seems obvious and fixes the proble
And one about the described general problem: http://bugzilla.lyx.org/
show_bug.cgi?id=3873
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
The bug report: http://bugzilla.lyx.org/show_bug.cgi?id=3854
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Here is a patch for the following problem:
Write something in a "Standard" layout paragraph. Change it into
Title.
The cursor will stay at the old position until the cursor blink
interval is over
There are many more those cases: Try to insert a math delimiter ("Alt-
m ("). The cursor s
I've tested it yesterday and it was OK so OK :-)
Is this in?
Yes: r18576
Stefan
Abdel.
--
José Abílio
PGP.sig
Description: Signierter Teil der Nachricht
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote:
>
> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>
> >>"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
> >
> >Stefan> This is fine, mostly. I don't like 7. There should be a
> >Stefan> position behind the c,
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote:
> So, removing the whole boundary business, we get this behavious:
>
> 1) abc| \ndef =right=> abc \n|def
> 2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
> 3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
> 4) abc\nd|ef =lef
On Wednesday 30 May 2007 07:09:59 Abdelrazak Younes wrote:
> I've tested it yesterday and it was OK so OK :-)
Is this in?
> Abdel.
--
José Abílio
Stefan Schimanski schrieb:
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e.
non-existing) end-of-par character at the end of each paragraph.
It does not care for cursor st
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-
existing) end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
Ah yes I remembered something about a virtual end-of-par.
It does not care for cur
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the thread but I hope that you did not kill any
CT-
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Good question. In 1.4.x, the two positions exist. I am not sure
>> why the position in front of the display inset is deemed useful.
Abdelrazak> Isn't this related to change-tracking?
I think it is something else, but what?
Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
Bu
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
But the visual effect will remain the same anyway.
I
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>>> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>>
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters appea
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters appear behind c. In fact
Stefan> the position in front of
So, removing the whole boundary business, we get this behavious:
1) abc| \ndef =right=> abc \n|def
2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
4) abc\nd|ef =left=> abc\ndef =left=> ab|c\ndef
5) abc|\ndef =right=> abc\n|def
6) abcd|ef =lef
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote:
> At least cursorLeft and cursorRight are much simpler now...
I have no idea whether the patch is sound, but I certainly like the
structure...
Andre'
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost) r
Dov Feldstern wrote:
Dov Feldstern wrote:
Dov Feldstern wrote:
Stefan Schimanski wrote:
There's also a separate case, but it doesn't manifest itself in
cursor movement (in terms of affecting the number of keystrokes
between positions):
if I'm between emph and normal text, and type a character
On Thu, May 31, 2007 at 12:14:25AM +0300, Dov Feldstern wrote:
> Andre Poenitz wrote:
> >
> >I am also uncertain whether
> >
> > cur.paragraph().isNewline(cur.pos() + 1) &&
> > cur.paragraph().isLineSeparator(cur.pos() + 1) &&
> > cur.para
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 30.05.2007 um 22:53 schrieb Dov Feldstern:
Dov Feldstern wrote:
Why should that correct? The condition will never be true because
no character is newline and separator at the same time.
Hmm... right... maybe some of those should be "or"s. Bu
Andre Poenitz wrote:
I am also uncertain whether
cur.paragraph().isNewline(cur.pos() + 1) &&
cur.paragraph().isLineSeparator(cur.pos() + 1) &&
cur.paragraph().isSeparator(cur.pos() + 1))
makes much sense.
Right, we're past that stage alrea
On Wed, May 30, 2007 at 11:12:32PM +0300, Dov Feldstern wrote:
> Index: lyx-devel/src/Text2.cpp
> ===
> --- lyx-devel.orig/src/Text2.cpp 2007-05-30 22:49:48.0 +0300
> +++ lyx-devel/src/Text2.cpp 2007-05-30 22:58:42.0
Stefan Schimanski wrote:
Am 30.05.2007 um 22:53 schrieb Dov Feldstern:
Dov Feldstern wrote:
Why should that correct? The condition will never be true because no
character is newline and separator at the same time.
Hmm... right... maybe some of those should be "or"s. But obviously
they're n
Am 30.05.2007 um 22:53 schrieb Dov Feldstern:
Dov Feldstern wrote:
Why should that correct? The condition will never be true because
no character is newline and separator at the same time.
Hmm... right... maybe some of those should be "or"s. But obviously
they're not really necessary at a
Dov Feldstern wrote:
Why should that correct? The condition will never be true because no
character is newline and separator at the same time.
Hmm... right... maybe some of those should be "or"s. But obviously
they're not really necessary at all... That's what I tried saying a few
days ago,
Dov Feldstern wrote:
Dov Feldstern wrote:
Stefan Schimanski wrote:
There's also a separate case, but it doesn't manifest itself in cursor
movement (in terms of affecting the number of keystrokes between
positions):
if I'm between emph and normal text, and type a character, should it
be emph o
Dov Feldstern wrote:
Stefan Schimanski wrote:
There's also a separate case, but it doesn't manifest itself in cursor
movement (in terms of affecting the number of keystrokes between
positions):
if I'm between emph and normal text, and type a character, should it be
emph or not? Well, if I'm co
Stefan Schimanski wrote:
Type a long line with no spaces (aa) until the line breaks
because it's too wide, and continue a bit. Then type a space, and then
b... until the moves to a new line.
Recall, there is no space in the middle of the , but there is a
space between aaa
Stefan Schimanski wrote:
Extended it a bit:
Index: src/DocIterator.h
===
--- src/DocIterator.h(Revision 18580)
+++ src/DocIterator.h(Arbeitskopie)
@@ -233,19 +233,42 @@
private:
/**
- * When the cursor position is i,
Type a long line with no spaces (aa) until the line breaks
because it's too wide, and continue a bit. Then type a space, and
then b... until the moves to a new line.
Recall, there is no space in the middle of the , but there is a
space between and .
So, start
Hi!
Attached find a patch to fix the following:
Type a long line with no spaces (aa) until the line breaks
because it's too wide, and continue a bit. Then type a space, and then
b... until the moves to a new line.
Recall, there is no space in the middle of the , but ther
Extended it a bit:
Index: src/DocIterator.h
===
--- src/DocIterator.h (Revision 18580)
+++ src/DocIterator.h (Arbeitskopie)
@@ -233,19 +233,42 @@
private:
/**
-* When the cursor position is i, is the cursor after
Stefan Schimanski wrote:
So moving forward (pos+1) but setting the boundary to true will not
register a movement; and staying at the same position, but changing
the boundary back to false, *will* appear to move. Is this correct?
The other way round: boundary=true => behind the char pos-1.
b
P.S. Stefan, just to make sure I really do understand: what I
hadn't understood until now is "so how does just setting the
boundary, without changing the position, make the cursor move?". I
think now I get it: when the cursor drawing is done, it looks at
the boundary: if the boundary is set
Stefan Schimanski wrote:
Please take care with those changes. Such a +1 can change and break a
lot. In this I am pretty sure that a character is skipped when going
over a newline. I added a special case for the RTL boundary for this line.
Okay, I think I understand (how many times have I s
(for http://bugzilla.lyx.org/show_bug.cgi?id=3754)
Index: src/Text2.cpp
===
--- src/Text2.cpp (revision 18569)
+++ src/Text2.cpp (working copy)
@@ -1031,7 +1031,7 @@
if (cur.pos() != cur.lastpos()) {
Stefan Schimanski wrote:
Abdel, is it ok? Dov tested it with my other patch already. Everything
looks fine ok.
Need another OK then.
I've tested it yesterday and it was OK so OK :-)
Abdel.
> Has anybody tried, especially those who reported a crash (which should be fixed by
the "row.pos()
> < par.size ()" change)?
This new patch works now. You have my OK to commit.
regards Uwe
On Tue, May 29, 2007 at 03:32:37PM +0200, Jean-Marc Lasgouttes wrote:
> > "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>
> Stefan> Using the cmake system. Anyway, now I enabled it and go indeed
> Stefan> a segfault... which is fixed in the revised patch below
> Stefan> (par.empty(
Dov Feldstern wrote:
Dov Feldstern wrote:
Attached is the patch against the new version of Stefan's patch.
Stefan, can you please see if it makes sense? I don't really fully
understand it, I tried various permutations and this one seems to work,
and doesn't appear to break anything else.
Will look tomorrow.
Stefan
Am 29.05.2007 um 22:56 schrieb Dov Feldstern:
Dov Feldstern wrote:
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
Stefan --- now that you're an expert on cursor movement and
boundary and all, do you think you could
Dov Feldstern wrote:
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
Stefan --- now that you're an expert on cursor movement and boundary
and all, do you think you could tackle a small remaining problem
with bidi cursor movement, which I think is
Abdel, is it ok? Dov tested it with my other patch already.
Everything looks fine ok.
Need another OK then.
Stefan
Am 29.05.2007 um 17:35 schrieb Stefan Schimanski:
Needing a second ok for this. Has anybody tried, especially those
who reported a crash (which should be fixed by the "row.pos(
Needing a second ok for this. Has anybody tried, especially those who
reported a crash (which should be fixed by the "row.pos() < par.size
()" change)?
Stefan
Am 29.05.2007 um 16:04 schrieb Stefan Schimanski:
Patch?
Posted in my message from around noon. Anyway, again:
Index: src/TextMet
Patch?
Posted in my message from around noon. Anyway, again:
Index: src/TextMetrics.cpp
===
--- src/TextMetrics.cpp (Revision 18552)
+++ src/TextMetrics.cpp (Arbeitskopie)
@@ -245,12 +245,9 @@
// Make sure that if a par end
Stefan Schimanski wrote:
Am 29.05.2007 um 15:32 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski
<[EMAIL PROTECTED]> writes:
Stefan> Using the cmake system. Anyway, now I enabled it and go indeed
Stefan> a segfault... which is fixed in the revised patch below
Stefan> (par.empty()
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I may be wrong but I think this bug is not valid anymore
Abdelrazak> thanks to the new target_x strategy (set on move up/down).
Abdelrazak> So there's nothing to replace. This trick was the rea
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I may be wrong but I think this bug is not valid anymore
Abdelrazak> thanks to the new target_x strategy (set on move up/down).
Abdelrazak> So there's nothing to replace. This trick was the reason
Abdelrazak> why the c
Am 29.05.2007 um 15:32 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Using the cmake system. Anyway, now I enabled it and go indeed
Stefan> a segfault... which is fixed in the revised patch below
Stefan> (par.empty() is not enough to test for
Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Using the cmake system. Anyway, now I enabled it and go indeed
Stefan> a segfault... which is fixed in the revised patch below
Stefan> (par.empty() is not enough to test for empty lines,
Stefan> par.si
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Using the cmake system. Anyway, now I enabled it and go indeed
Stefan> a segfault... which is fixed in the revised patch below
Stefan> (par.empty() is not enough to test for empty lines,
Stefan> par.size()==row.pos() is though
Let's move it to the list...
Am 29.05.2007 um 10:49 schrieb [EMAIL PROTECTED]:
http://bugzilla.lyx.org/show_bug.cgi?id=2475
--- Additional Comments From [EMAIL PROTECTED] 2007-05-29
10:49 ---
Stefan, do you use --enable-stdlib-debug? The crash sent by Dov is
an assert
from this co
Patch is attached to http://bugzilla.lyx.org/show_bug.cgi?id=2475.
Can somebody with deeper understanding please comment why this "dirty
trick" was needed? Haven't found any bad effect without it.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 27.05.2007 um 02:27 schrieb Dov Feldstern:
Stefan --- now that you're an expert on cursor movement and boundary
and all, do you think you could tackle a small remaining problem with
bidi cursor movement, which I think is very much connected wi
On Thu, Apr 07, 2005 at 05:10:48PM +0300, Martin Vermeer wrote:
> > I know I am repeating myself, but we should understand the
> > LFUN_FINISHED stuff before doing that. Either it makes sense and we
> > should fix it, or it does not, and we should remove it completely.
The main purpose of the LFUN
On Wed, Apr 06, 2005 at 06:09:10PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Nice, those small attachments ;-/
>
> case LFUN_UPSEL:
> case LFUN_UP:
> + if (cur.inMacroMode()) break;
> cur.sel
On Thu, Apr 07, 2005 at 11:36:22AM +0200, Helge Hafting wrote:
> Apparently, there are fundamental differences between
> going up/down and left/right.
Up/down is mainly 'visual by coordinate', left/right 'by structure'.
There are exceptions when following these base rules is 'obviously'
wrong. Up/
On Wed, Apr 06, 2005 at 06:51:22PM +0300, Martin Vermeer wrote:
> OK, here's a patch for this one. The problem is an unfinished math macro
> is already defined as an inset, but hasn't drawn + added a coordinate
> cache entry yet. So it now tests for macro mode and does nothing then.
There is at mo
On Fri, 2005-04-08 at 15:05, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Thu, Apr 07, 2005 at 03:58:00PM +0200, Jean-Marc Lasgouttes
> Martin> wrote:
> >> I know I am repeating myself, but we should understand the
> >> LFUN_FINISHED st
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Thu, Apr 07, 2005 at 03:58:00PM +0200, Jean-Marc Lasgouttes
Martin> wrote:
>> I know I am repeating myself, but we should understand the
>> LFUN_FINISHED stuff before doing that. Either it makes sense and we
>> should fix it,
Martin Vermeer wrote:
>> Ideally, the first arrow down/up should move the cursor,
>> not merely close the macro. I guess that is much harder to do?
>
> Yes, I didn't manage that. The problem seems to be that we have to first
> force a redraw/setPosCache after closing the macro, before we are
> a
On Fri, 2005-04-08 at 11:11, Helge Hafting wrote:
> Martin Vermeer wrote:
...
> >This is the part that is unrelated to LFUN_FINISHED: it fixes
> >Helge's bug and does nothing else. It's a crashing bug and this is the
> >correct fix IMHO*). Agreed?
> >
> >
> This works fine. No more crash when
Martin Vermeer wrote:
On Thu, Apr 07, 2005 at 03:58:00PM +0200, Jean-Marc Lasgouttes wrote:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Here is the patch fixing Helge's unfinished macro up/down bug,
Martin> as well as making the cursor move properly for HOME/END
On Thu, Apr 07, 2005 at 03:58:00PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Here is the patch fixing Helge's unfinished macro up/down bug,
> Martin> as well as making the cursor move properly for HOME/END. Also
> Martin> a slight
On Thu, Apr 07, 2005 at 03:58:00PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Here is the patch fixing Helge's unfinished macro up/down bug,
> Martin> as well as making the cursor move properly for HOME/END. Also
> Martin> a slight
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Here is the patch fixing Helge's unfinished macro up/down bug,
Martin> as well as making the cursor move properly for HOME/END. Also
Martin> a slight simplification/dead code removal.
Martin> Unfortunately I didn't get Page Up/D
Here is the patch fixing Helge's unfinished macro up/down bug, as well as
making the
cursor move properly for HOME/END. Also a slight simplification/dead code
removal.
Unfortunately I didn't get Page Up/Down to behave, so I left that part out.
OK to commit? Works for me.
- Martin
Index: Cha
On Thu, Apr 07, 2005 at 11:36:22AM +0200, Helge Hafting wrote:
> Martin Vermeer wrote:
...
> >Just give it a try anyway ;-)
> >
> >
> Did that.
> The crash is gone, and replaced with inconvenience. ;-)
> I can now type in math latex like \bmod, and if I
> press down while it is still red, nothi
Martin Vermeer wrote:
This did not apply to yesterday's CVS (plus those
patches for paranthesis issues.)
Two hunks would apply with offsets, two were rejected.
Probably because they were already in. You could check for that.
Ok, they were in already. :-)
Just give it a try anyway ;-)
Did
Martin Vermeer wrote:
> On Wed, Apr 06, 2005 at 06:09:10PM +0200, Jean-Marc Lasgouttes wrote:
>> Why don't you use cur.macroModeClose() as for LFUN_LEFT/RIGHT?
>>
>> JMarc
>
> I tried that; didn't do the trick :-(
> Neither did cur.clearTargetX() by the way.
Could you please add a FIXME comment
On Thu, Apr 07, 2005 at 09:50:48AM +0200, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >
> >>OK, here's a patch for this one. The problem is an unfinished math macro
> >>is already defined as an inset, but hasn't drawn + added a coordinate
> >>cache entry yet. So it now tests for macro mode an
Martin Vermeer wrote:
OK, here's a patch for this one. The problem is an unfinished math macro
is already defined as an inset, but hasn't drawn + added a coordinate
cache entry yet. So it now tests for macro mode and does nothing then.
(Were there any other keys that did this?)
This contains the n
On Wed, Apr 06, 2005 at 06:09:10PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Nice, those small attachments ;-/
>
> case LFUN_UPSEL:
> case LFUN_UP:
> + if (cur.inMacroMode()) break;
> cur.sel
On Wed, Apr 06, 2005 at 06:03:02PM +0200, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > OK, here's a patch for this one. The problem is an unfinished math macro
> > is already defined as an inset, but hasn't drawn + added a coordinate
> > cache entry yet. So it now tests for macro mode and does
Jean-Marc Lasgouttes wrote:
> Why don't you use cur.macroModeClose() as for LFUN_LEFT/RIGHT?
I think that that would be the correct fix, but I suspect (untested) that
macroModeClose() invalidates the coord cache, because it removes the
unfinished inset and inserts a new one. But if this is the ca
Martin Vermeer wrote:
> OK, here's a patch for this one. The problem is an unfinished math macro
> is already defined as an inset, but hasn't drawn + added a coordinate
> cache entry yet. So it now tests for macro mode and does nothing then.
>
> (Were there any other keys that did this?)
What do
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Nice, those small attachments ;-/
case LFUN_UPSEL:
case LFUN_UP:
+ if (cur.inMacroMode()) break;
cur.selHandle(cmd.action == LFUN_UPSEL);
if (!cur.up())
On Wed, 2005-04-06 at 18:51, Martin Vermeer wrote:
> On Wed, 2005-04-06 at 10:15, Martin Vermeer wrote:
> > On Tue, Apr 05, 2005 at 11:03:19PM +0200, Helge Hafting wrote:
> > > Move into a math inset.
> > > Type \bmod
> > > It will show as red text. Press down arrow while it still is red,
> > > a
On Wed, 2005-04-06 at 10:15, Martin Vermeer wrote:
> On Tue, Apr 05, 2005 at 11:03:19PM +0200, Helge Hafting wrote:
> > Move into a math inset.
> > Type \bmod
> > It will show as red text. Press down arrow while it still is red,
> > and lyx crashes with the usual emergency save.
> >
> > Pressing
On Fri, Apr 01, 2005 at 05:42:30PM +0300, Martin Vermeer wrote:
>
> Attached is a patch that fixes this cursor positioning problem for math
> insets-within-insets. I don't like it very much but it works, and it is
> based on an understanding of the bug's mechanism, which is always
> comforting. (W
On piÄtek 10 grudzieÅ 2004 01:49 pm, Andre Poenitz wrote:
> On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote:
> > Is this ok [self-explaining patch attached], or are there some kind of
> > moral reasons for not showing half a cursor?
>
> I am not sure we are allowed to show the lo
On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote:
> Is this ok [self-explaining patch attached], or are there some kind of moral
> reasons for not showing half a cursor?
I am not sure we are allowed to show the lower part of a cursor to
minors at all.
Andre'
Alfredo Braunstein wrote:
> Is this ok [self-explaining patch attached], or are there some kind of
> moral reasons for not showing half a cursor?
Looks sensible to me.
--
Angus
Is this ok [self-explaining patch attached], or are there some kind of moral
reasons for not showing half a cursor?
Alfredo
Index: screen.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/screen.C,v
retrieving revision 1.
On Tue, Apr 13, 2004 at 11:24:08AM +0200, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > Not sure if this is the "correct" solution though. The top_y habdling
> > should be probably completely centralized in some setCachePos like in
> > insets/, but I've lost track inside the math/ hi
Alfredo Braunstein wrote:
> Not sure if this is the "correct" solution though. The top_y habdling
> should be probably completely centralized in some setCachePos like in
> insets/, but I've lost track inside the math/ hierarchy.
Andre', could you have a look? It just adds top_y in a couple of pla
Not sure if this is the "correct" solution though. The top_y habdling should
be probably completely centralized in some setCachePos like in insets/, but
I've lost track inside the math/ hierarchy.
I think we should put bv.top_y inside PainterInfo directly so we can avoid
including BufferView.h in
Andre Poenitz wrote:
> On Mon, Mar 22, 2004 at 11:39:59AM +, Angus Leeming wrote:
>> Gets rid of the unused nopop_ variable and rewrites
>> Cursor::dispatch to:
>> 1. Get rid of the horrible 'operator=(safe)' call;
>> 2. Make clear that the only member variable updated is
>> Cursor::disp_:
>>
On Mon, Mar 22, 2004 at 11:39:59AM +, Angus Leeming wrote:
> Gets rid of the unused nopop_ variable and rewrites Cursor::dispatch
> to:
> 1. Get rid of the horrible 'operator=(safe)' call;
> 2. Make clear that the only member variable updated is Cursor::disp_:
>
> DispatchResult LCursor::disp
1 - 100 of 128 matches
Mail list logo
