On Mon, Jan 23, 2006 at 11:40:30PM +0200, Martin Vermeer wrote:
> That must have been a long time ago, when you were still on coffee...
It was never coffee. Just tea.
Andre'
On Mon, Jan 23, 2006 at 08:05:48PM +0100, Andre Poenitz wrote:
> On Mon, Jan 23, 2006 at 11:29:02AM +0200, Martin Vermeer wrote:
> > On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> > > This code compares pits,
On Mon, Jan 23, 2006 at 11:29:02AM +0200, Martin Vermeer wrote:
> On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > Martin> Ah yes... thanks. The attached should be OK in this respect.
> >
> >
> > I do not thin
On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Ah yes... thanks. The attached should be OK in this respect.
>
>
> I do not think so:
> - for ( ; it != et; it.forwardPos()) {
> + fo
On Mon, 2006-01-23 at 09:34 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> A patch for this is attached. An unbelievable story really...
> Martin> when doing cursor up/down, the new y co-ordinate is just _one
> Martin> pixel_ into the
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> This is nice and snappy. (Why would using the cache be
Martin> better?)
Using the cache is better for fixing bruteFind. You approach fixes a
different problem, in some sense.
JMarc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Ah yes... thanks. The attached should be OK in this respect.
I do not think so:
- for ( ; it != et; it.forwardPos()) {
+ for ( ; it != et && it.pit() < from + 2; it.forwardPos()) {
This code compa
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> BTW, in
Martin> inset->cursorPos(it.top(), c.boundary() && ((i+1) ==
Martin> it.depth()), xo, inset-> yo);
Martin> what precisely is the (i+1) == it.depth() condition for? Looks
Martin> nonsensical to me. i is the counter of doc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> A patch for this is attached. An unbelievable story really...
Martin> when doing cursor up/down, the new y co-ordinate is just _one
Martin> pixel_ into the next/previous row! Therefore the test for
Martin> being inside a math ins
On Sun, 2006-01-22 at 20:43 +0100, Andre Poenitz wrote:
> > The patch makes cursor movement a little more generous ;-)
>
> A comment stating this would be in order...
>
> Andre'
OK, see attached.
Would somebody test this, please?
Further remarks:
1) I don't think it is possible to get this co
> The patch makes cursor movement a little more generous ;-)
A comment stating this would be in order...
Andre'
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
| > On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
| > > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
| > > > > "Martin" == Martin Vermeer <[EM
On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> ...
>
> BTW2, we stil
On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> ...
>
> > It's snappy
On Fri, Jan 20, 2006 at 04:11:24PM +0100, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I have some questions/points for you...
>
> + // Unsafe if .find() can return .end()
> CoordCache::InnerParPosCache const & cache =
> theCoords.getPa
On Sat, Jan 21, 2006 at 05:59:08PM +0100, Georg Baum wrote:
> Am Samstag, 21. Januar 2006 13:13 schrieb Martin Vermeer:
> > About the rottenness, one thing is that in bruteFind2, the co-ordinates
> > xo, yo produced by the cursorPos call are relative, while the arguments
>
> There is an explanatio
Am Samstag, 21. Januar 2006 13:13 schrieb Martin Vermeer:
> About the rottenness, one thing is that in bruteFind2, the co-ordinates
> xo, yo produced by the cursorPos call are relative, while the arguments
There is an explanation about relative/absolute coordinates in some math
header file, but I
On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> It's snappy for me... BTW there is something rotten also in cursor
> positioning _inside_
On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> The slowness is really huge, so yes, that's what I think.
>
> Martin> I didn't give up though... attached a modification of
> Martin> bruteFind3 that do
Did I send this one already? Don't see it on the list.
This searches previous, current and next paragraph. I made bruteFind3 do
this, which was also simpler than I thought... and, I think, rather
risk-free.
This is nice and snappy. (Why would using the cache be better?)
...and what shall we do
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I have some questions/points for you...
+ // Unsafe if .find() can return .end()
CoordCache::InnerParPosCache const & cache =
theCoords.getParPos().find(cursor.bottom().text())->second;
bv::funcs::status does the same, so it
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> The slowness is really huge, so yes, that's what I think.
Martin> I didn't give up though... attached a modification of
Martin> bruteFind3 that does the three-paragraph trick. There is still
Martin> a slight delay, but it's much
On Fri, 2006-01-20 at 13:19 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> The other one would "fix" this bug by just moving to in
> Martin> front/behind the math inset. Ugly, but it remembers the x
> Martin> location when you press fu
Jean-Marc Lasgouttes wrote:
> The code that initializes the iterators looks a bit ugly, but it can
> be
> - factored out somewhere in bufferview.C
> - probably improved by someone who is better at STL than I am.
>
> I think it works, and would be interested by some testing. I believe
> the bruteF
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Searching the coordcache would be better.
Martin> I'm sure it would be possible, but too risky now for 1.4.0.
Here is what I have in mind. My assumptions here are that
1/ in a map, the elements are ordered wrt the key (pit_type he
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> The other one would "fix" this bug by just moving to in
Martin> front/behind the math inset. Ugly, but it remembers the x
Martin> location when you press further cursor ups/downs.
>> That is kind of ugly indeed. I was about to s
On Fri, 2006-01-20 at 11:17 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Yes. The one modifying bruteFind was rejected by Lars, on the
> Martin> ground (sound IMO) that he wants to keep that as a
> Martin> super-general find routine
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes. The one modifying bruteFind was rejected by Lars, on the
Martin> ground (sound IMO) that he wants to keep that as a
Martin> super-general find routine for when everything else fails.
I think it is possible to fix bruteFind
On Thu, Jan 19, 2006 at 04:17:15PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> >> The following patch gets rid of some debug output. It also improves
> >> some Counter
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Please change this to "Setting new encoding for Qt:" which is
Martin> correct. My bad in Paris ;-)
I did so and committed.
JMarc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
>> The following patch gets rid of some debug output. It also improves
>> some Counters error messages to be more useful (I saw these with
>> beamer.layout).
>>
>> L
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch gets rid of some debug output. It also improves
| some Counters error messages to be more useful (I saw these with
| beamer.layout).
|
| Lars, OK?
ok
--
Lgb
On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> The following patch gets rid of some debug output. It also improves
> some Counters error messages to be more useful (I saw these with
> beamer.layout).
>
> Lars, OK?
- lyxerr << "Setting new locale for Qt:" << s << endl;
+
On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> The following patch gets rid of some debug output. It also improves
> some Counters error messages to be more useful (I saw these with
> beamer.layout).
>
> Lars, OK?
Didn't you find goUpDown (moving up and down through math insets)
The following patch gets rid of some debug output. It also improves
some Counters error messages to be more useful (I saw these with
beamer.layout).
Lars, OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-deve
35 matches
Mail list logo
