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
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
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 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
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
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
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 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
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
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
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | When I think about it: Has anybody ever tried to use a std::vector<>
>> | (-like container) instead of a std::list<> as text contai
On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | When I think about it: Has anybody ever tried to use a std::vector<>
> | (-like container) instead of a std::list<> as text container?
>
> You loose the fast undo/paste stuff. si
Andre Poenitz <[EMAIL PROTECTED]> writes:
| When I think about it: Has anybody ever tried to use a std::vector<>
| (-like container) instead of a std::list<> as text container?
You loose the fast undo/paste stuff. since you will need to
reallocate... with std::list a splice is done.
What are the
On Thu, Mar 11, 2004 at 11:38:16AM +0100, Alfredo Braunstein wrote:
> > (1) A 'stable' iterator not dependent on the location of some random
> > chunk in memory (aka 'pointer'). Ok, that was already defeated by having
> > the inset_ cache, but my original intention wsa to get rid of that.
>
> Why
Andre Poenitz wrote:
> No, both have to be kept in sync. This should be O(1) though for
> standard operations like initialization, one up, one down etc.
>
>> Doesn't that defeat the purpose of having the offset at all
>
> Partially, yes.
>
>> (hum... what was it again)?
>
> (1) A 'stable' iter
On Wed, Mar 10, 2004 at 09:05:40AM +0100, Alfredo Braunstein wrote:
> > The obvious idea is to use and/or cache some ParagraphList iterator
> > instead of the par offset...
> >
> > Maybe we've to use both. In fact, it's almost the same as with the
> > 'inset_' member: This is just a form of a cach
Andre Poenitz wrote:
> The obvious idea is to use and/or cache some ParagraphList iterator
> instead of the par offset...
>
> Maybe we've to use both. In fact, it's almost the same as with the
> 'inset_' member: This is just a form of a cache itself.
Right.
> So we'd remove the 'paroffset_type
On Tue, Mar 09, 2004 at 09:25:29AM +0100, Alfredo Braunstein wrote:
> On Friday 05 March 2004 19:45, Andre Poenitz wrote:
> > > On Thursday 04 March 2004 17:15, you wrote:
> > >> > Do you have an idea why is it slow?
> > >>
> > >> No(t yet).
> > >
> > > Looking at it a bit closely, I do. I'm pretty
Andre Poenitz wrote:
> In theory, this could be used in undo instead of the current triplet
> (quadrupel) of data. Unfortunately, DocIterator is too slow for it
> (currently) (~30s for traversing the UserGuide)
Do you have an idea why is it slow? We should make it fast enough; then we
could ditch
On Mon, Mar 01, 2004 at 03:31:34PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This splits the cursor into an 'iterator' part (that can be
> > reused...) and a 'selection handling + real cursor stuff' part.
> > Reason should be obvious.
>
> The patch doesn't contain "dociterator
Andre Poenitz wrote:
>
> This splits the cursor into an 'iterator' part (that can be
> reused...) and a 'selection handling + real cursor stuff' part.
> Reason should be obvious.
The patch doesn't contain "dociterator.[Ch]". Just three references
to their existence.
There appear to be some con
Andre Poenitz wrote:
>
> This splits the cursor into an 'iterator' part (that can be reused...)
> and a 'selection handling + real cursor stuff' part. Reason should be
> obvious.
could you send dociterator.[Ch] please?
Alfredo
On Fri, Feb 13, 2004 at 09:48:25AM +0100, Alfredo Braunstein wrote:
> fixes a crash and a coord problem.
Good.
Btw: All the setCursorFromCoordinates without CursorSlice argument
should die..
> @@ -1468,7 +1468,7 @@ void LyXText::cursorUp(LCursor & cur, bo
> Row const & row = cur.textRow(
On Mon, Oct 13, 2003 at 04:53:24PM +0300, Martin Vermeer spake thusly:
>
> At least this fixes one of them. (It took the cursor position inside
> the inset and compared it with the length of the paragraph containing
> the inset. Works OK as long as the inset content is longer than the
> containing
Lars Gullik Bjønnes wrote:
> I am pretty satisfied by my AMD XP-2000+ works like a charm.
Hmm, so you will send it to me, or how am I expected to work on it :P
Jug
P.S.: My comment about buying a new PC was serious I just have to look
up on one first /AND/ I will by something that
Juergen Vigna <[EMAIL PROTECTED]> writes:
| John Levon wrote:
>> On Tue, Sep 10, 2002 at 06:02:19PM +0200, Jean-Marc Lasgouttes wrote:
>>
>>>Do you know that there a few few bad undo bugs waiting for you in
>>>bugzilla?
>> There are some bad cosmetic table problems too ;)
>
| I know, I know and m
John Levon wrote:
> On Tue, Sep 10, 2002 at 06:02:19PM +0200, Jean-Marc Lasgouttes wrote:
>
>
>>Do you know that there a few few bad undo bugs waiting for you in
>>bugzilla?
>
>
> There are some bad cosmetic table problems too ;)
I know, I know and maybe in the near future I will buy myself a
On Tue, Sep 10, 2002 at 06:02:19PM +0200, Jean-Marc Lasgouttes wrote:
> Do you know that there a few few bad undo bugs waiting for you in
> bugzilla?
There are some bad cosmetic table problems too ;)
regards
john
--
"This *is* Usenet, after all, where virtually every conversation that goes on
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>>> "Michael" == Michael Schmitt <[EMAIL PROTECTED]>
>>> writes:
>>
Michael> Hi, I think I can contribute a one-line patch to the problem
Michael> that the cursor positioning is inprecise
Jean-Marc Lasgouttes wrote:
>>"Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
>
>
> Michael> Hi, I think I can contribute a one-line patch to the problem
> Michael> that the cursor positioning is inprecise in lines which
> Michael> include hfills.
>
> Michael> The patch is again
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hi, I think I can contribute a one-line patch to the problem
Michael> that the cursor positioning is inprecise in lines which
Michael> include hfills.
Michael> The patch is against 1.2.2cvs. Could anybody with a little
Micha
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> Michael Schmitt wrote:
>> Hi, I think I can contribute a one-line patch to the problem that
>> the cursor positioning is inprecise in lines which include hfills.
>> The patch is against 1.2.2cvs. Could anybody with a little bit
Michael Schmitt wrote:
> Hi,
>
> I think I can contribute a one-line patch to the problem that the cursor
> positioning is inprecise in lines which include hfills.
>
> The patch is against 1.2.2cvs. Could anybody with a little bit more
> knowledges of the LyX code than myself please check the
97 matches
Mail list logo
