Jürgen Spitzmüller wrote:
> Could you resend the testcase as a proper attachment, please?
Here included
--
Pol
test-label.lyx
Description: application/lyx
On 7/5/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
John McCabe-Dansted wrote:
> I tried doing a make clean && make. Didn't help. I am using Fedora
> Core 6 with the following CFLAGS and gcc. Perhaps someone using
FYI, removing the CFLAGS didn't help.
> Fedora Core 6 could try to reprodu
Selon Jean-Marc Lasgouttes :
> Mael> It seems that we explored the facts of the matter now...
>
> Mael> Opinions from developers? Hopefully, that will lead to a decision.
>
> My opinion:
>
> 1/ this is not an urgent matter and now is not the right time for that
Perhaps. However I thought it would
John McCabe-Dansted wrote:
> I tried doing a make clean && make. Didn't help. I am using Fedora
> Core 6 with the following CFLAGS and gcc. Perhaps someone using
> Fedora Core 6 could try to reproduce the bug?
Could you provide a backtrace?
Jürgen
On 7/5/07, Michael Gerz <[EMAIL PROTECTED]> wrote:
I cannot reproduce this bug.
I tried doing a make clean && make. Didn't help. I am using Fedora
Core 6 with the following CFLAGS and gcc. Perhaps someone using
Fedora Core 6 could try to reproduce the bug?
In the mean while, I'll take out th
pol wrote:
> Here is a lyx 1.4.4 one-line file, where two labels have been included.
> As i try to insert a cross reference to one label by choosing 'apply' in
> the panel, lyx crashes. Choosing 'ok' rather than 'apply' works as
> expected, instead
> Can anybody reproduced that?
> thank you
Could
I want to be able to guess in advance whether the thing is going to
work or not.
My patch fixes 3877 and middle-button paste works, let us just say,
90% of the times. I expect that other 10% cases can be discovered and
fixed easily (just a few missing saveSelection calls).
If this solution is c
Following our middle-mouse pasting discussions, I think I've implemented
the optimal solution that will work under Mac and Windows too
(internally to LyX). My solution is to save the selectionBuffer just
before it is pasted in the same LFUN_MOUSE_PRESS. The big change is that
we check if the curre
Jean-Marc Lasgouttes wrote:
"Dov" == Dov Feldstern
writes:
Dov> I think that I'll try to create a constructor which accepts a
Dov> font to be used as the initial font. Does this sound all right?
That may turn out to be complicated. Do you really need to set the
font in the constructor? If yo
Dear Andreas,
Yes, that solved the problem. Thank you for the tip.
My LDFLAGS now reads:
LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework
QuickTime -lz -framework Cocoa -liconv
I wonder if the file INSTALL.MacOSX in the source distribution should
sometime be changed t
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> A const method should return a const object. If you want to
Jean-Marc> go this route, the best may be to declare 'used_' as
Jean-Marc> mutable.
Je
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Trenton" == Trenton Schulz <[EMAIL PROTECTED]> writes:
Trenton> Yes, the path to the headers. In the binary package, they are
Trenton> only stored _inside_ the frameworks. So I would need a path
Trenton> similar to -I/ Li
> "Mikhail" == Mikhail T <[EMAIL PROTECTED]> writes:
Mikhail> The patch is for configure.ac, which I don't use :) I don't
Mikhail> even have autoconf-2.61 (only 2.59), which is needed to
Mikhail> regenerate configure after applying your patch. I guess, the
Mikhail> patch would work...
José,
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> A const method should return a const object. If you want to
Jean-Marc> go this route, the best may be to declare 'used_' as
Jean-Marc> mutable.
Something like that. I tested briefly with 3 different authors, and I
th
Mael> It seems that we explored the facts of the matter now...
Mael> Opinions from developers? Hopefully, that will lead to a decision.
My opinion:
1/ this is not an urgent matter and now is not the right time for that
2/ I prefer to have a different lfun to do the edition
3/ Pressure is not
Hi!
Attached find the (I hope) final version of this patch. I addressed all
of the issues which Georg pointed out (Georg, please make sure), and
tested this again.
I think that this should go in for 1.5.0 if possible, so if I get
another OK (I'm assuming Georg's unless I hear otherwise) I'll
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Jean-Marc Lasgouttes schrieb:
>> http://bugzilla.lyx.org/show_bug.cgi?id=3764
>>
>> I do not like this patch very much, actually %-| The name
>> AuthorActive is ugly, the class definition in Author.h is weird
>> (but better IMO
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> In contrary, I am not responsible for "usedtoolbars" and it
Michael> wasn´t my intention to clean up or refactor this area of the
Michael> code.
Michael> Moreover, IMHO it does not make sense to call "hasToolbar"
Michael> bef
Le 4 juil. 07 à 16:23, Mael Hilléreau a écrit :
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
Mael Hilléreau wrote:
Yes, I totally agree. But you might know that the patch, as well
as the
current behavior of the "Load" button, don't exclude anything.
When you've
displayed a dialog once, yo
Pol,
please add a report to bugzilla.lyx.org if this problem occurs with 1.5.0svn
Michael
pol schrieb:
Here is a lyx 1.4.4 one-line file, where two labels have been included.
As i try to insert a cross reference to one label by choosing 'apply' in the
panel, lyx crashes. Choosing 'ok' rathe
John,
I cannot reproduce this bug.
Michael
John McCabe-Dansted schrieb:
To reproduce:
1) Press Cntl-N (start new file)
2) Press Alt-I, I, B (insert TOC from BibTeX)
3) Press Alt-A (Add...)
4) Double Click test
5) Press Alt-O (OK)
6) Press Alt-I C (Insert Citation)
7) Press Alt-A (Add)
LyX no
Hi,
it seems that there are still several patches that may go into 1.5.0.
Since José has left us for the rest of the week, I wonder what will
happen to these patches:
- RTL Justification Bug (bug3889.2.patch, 26/06/07) by Dov
- Bug fix #3600 (30/06/07) by Alfredo
- Image Cache Fix (3819.diff,
Jean-Marc Lasgouttes schrieb:
http://bugzilla.lyx.org/show_bug.cgi?id=3764
I do not like this patch very much, actually %-| The name AuthorActive
is ugly, the class definition in Author.h is weird (but better IMO
than including everywhere).
Jean-Marc,
I think I found a smarter solution tha
Folks,
Some earlier posts suggested that the slow text entry problem on mac
PPC machines has been solved. I don't think so.
Could people please try the following test. Open the attached file
(AidOfTheirParty-1.lyx) in lyx 1.5rc2 or lyx 1.5rc1 on a ppc
machine. Place the cursor just aft
On 04.07.2007, at 17:13, Andreas Neustifter wrote:
On 04.07.2007, at 09:48, Abdelrazak Younes wrote:
What I need is some profiling results when my patch is applied. Do
you know how to do that with Shark? If not maybe Bennett or Stefan
could give you a hand. The important bits is to compile i
Jean-Marc Lasgouttes schrieb:
José> I was expecting Jean-Marc opinion on this.
My opinion:
- I do not know what this 'usedtoolbars' thing is. And the comments in
ToolbarBackend.h do not help much. Edwin, is it your doing?
- it seems that the problem was that we need to check whether a given
On 7/4/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bob Lounsbury wrote:
> On 7/3/07, Andreas Neustifter
> <[EMAIL PROTECTED]> wrote:
>> On 03.07.2007, at 16:46, Abdelrazak Younes wrote:
>> > I'm afraid I don't follow you :-( Does the patch improves the
>> > situation significantly or not?
>>
On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> It seems that once you have used AddFontResource to add a font
> Enrico> file, you have no choice and cannot move them from the
> Enrico> original po
Jean-Marc Lasgouttes wrote:
> Just wait a bit. Juergen, I thought we were no supposed to load child
> documents just for the pleasure of displaying bibkeys. I seem to
> remember fixes in this area some time ago. Do you remember?
Yes. The child documents should not be loaded for this IIRC. If they
On 04.07.2007, at 09:48, Abdelrazak Younes wrote:
What I need is some profiling results when my patch is applied. Do
you know how to do that with Shark? If not maybe Bennett or Stefan
could give you a hand. The important bits is to compile in release
mode, that is to say, with some optimisa
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> It was not very easy to find but the fix is simple and is
Abdelrazak> obvious once found. The problem is that a screen update
Abdelrazak> needs a bibtex key for proper rendering of the Citation.
Abdelrazak> This key re
It was not very easy to find but the fix is simple and is obvious once
found.
The problem is that a screen update needs a bibtex key for proper
rendering of the Citation. This key requires the master document to load
all child document, which trigger an additional screen update, even when
we do
Jean-Pierre Chrétien <[EMAIL PROTECTED]> writes:
>
> Jean-Pierre Chrétien ...> writes:
>
> > >
> > > I cannot reproduce this here (Solaris 10/Qt 4.2.2).
> >
> > Solaris 8/Qt 4.2.1 here, rather Qt than Sun I guess.
> > I will check with 4.2.2
>
> My admin compiled 4.2.3, same behaviour, makes
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> The only side effect is a case is missing is that the selection
>> buffer is lost: not big deal!
Bo> This is what I was going to say. With this patch, 3877 is gone,
Bo> and middle button paste works in most of the cases, if not 100%.
Bo> saveSe
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> It seems that once you have used AddFontResource to add a font
Enrico> file, you have no choice and cannot move them from the
Enrico> original position, otherwise they will not be found. I am
Enrico> really disgusted.
Until y
> Yes, I think this patch is very fragile,
Actually, it is not because:
> and I would be indeed
> surprised if it catches all cases.
The only side effect is a case is missing is that the selection buffer
is lost: not big deal!
This is what I was going to say. With this patch, 3877 is gone, an
On Wed, Jul 04, 2007 at 01:08:18PM +0200, Enrico Forestieri wrote:
> On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote:
> > As JMarc suggested, does it work when you rename the font file, and
> > remove the _LyX from the patch?
>
> No, as I already tried to say. What is worse is that Ad
This looks interesting. Anyone want to make a lyx conversion for this?
http://www.arakhne.org/spip.php?article52
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Instead of saveSelection when a selection is formed, this patch
saves a selection when it is cleared. This sounds strange so let me
explain:
Abdelrazak> Sorry Bo but I think this patch is too complicate
Bo Peng wrote:
Analysis:
Previously, any selection action triggers saveSelection, which saves
selection and calls theSelection().haveSelection(cur.selection());.
Therefore, when selecting with page down, saveSelection will be called
many times, with larger and larger selected texts saving to the
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
> Mael Hilléreau wrote:
> > Yes, I totally agree. But you might know that the patch, as well as the
> > current behavior of the "Load" button, don't exclude anything. When you've
> > displayed a dialog once, you know for sure how to display it again! .
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hi,
Following our middle-mouse pasting discussions, I think I've
implemented the optimal solution that will work under Mac and Windows
too (internally to LyX). My solution is to save the selectionBuffer
just before it is pasted in the same LF
Mael Hilléreau wrote:
> Yes, I totally agree. But you might know that the patch, as well as the
> current behavior of the "Load" button, don't exclude anything. When you've
> displayed a dialog once, you know for sure how to display it again! ... if
> you need it. Moreover, that's very easy in this
Mael Hilléreau wrote:
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
Mael Hilléreau wrote:
BTW, did you already heard about users complaining about the "Load" button?
I didn't complain about it because I actually never used that button. Now
that
I'm aware of it, I complain (not too loud, thoug
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
> Mael Hilléreau wrote:
> > Do you mean that performing action "Load" implies performing action "change
> > parameters" just after?
>
> No, it doesn't imply this. But it also doesn't exclude it. I.e. there's no
> reason why a user wouldn't change param
On Wed, 4 Jul 2007, Enrico Forestieri wrote:
I did catch a reference to that bit, but I felt someone should argue
against things (roughly) like:
* Windows users don't need "unixy" stuff
So they don't need LyX? ;-)
Exactly ;-)
* No other Windows program does it like that
This is not true.
Mael Hilléreau wrote:
> Do you mean that performing action "Load" implies performing action "change
> parameters" just after?
No, it doesn't imply this. But it also doesn't exclude it. I.e. there's no
reason why a user wouldn't change parameters after "Loading", e.g. in the
case of an included l
Abdelrazak Younes wrote:
Hi,
Following our middle-mouse pasting discussions, I think I've implemented
the optimal solution that will work under Mac and Windows too
(internally to LyX). My solution is to save the selectionBuffer just
before it is pasted in the same LFUN_MOUSE_PRESS. The big ch
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
> Mael Hilléreau wrote:
> > BTW, did you already heard about users complaining about the "Load" button?
>
> I didn't complain about it because I actually never used that button. Now
> that
> I'm aware of it, I complain (not too loud, though ;-))
Good
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Yes, it is. And it's an ui bug IMHO. Thanks for pointing that
Jürgen> out. Attached is a patch that fixes this. OK to commit?
Yes.
Jürgen> The proper solution here would as well be to take this
Jürgen> function out of the d
Mael Hilléreau wrote:
> BTW, did you already heard about users complaining about the "Load" button?
I didn't complain about it because I actually never used that button. Now that
I'm aware of it, I complain (not too loud, though ;-))
> If no, this button behavior isn't so bad for the moment. Mor
On Wed, Jul 04, 2007 at 09:24:45AM +0200, [EMAIL PROTECTED] wrote:
> On Wed, 4 Jul 2007, Jürgen Spitzmüller wrote:
>
> > [EMAIL PROTECTED] wrote:
> >> To be more serious, why should we restrict Windows users from
> >> functionality we appreciate elsewhere?
> >
> > Please read the whole thread: be
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
> Mael Hilléreau wrote:
> > Well, then the UI is IMO already unintuitive. We have two separate actions:
> >
> > 1) Edit the external file;
> > 2) Edit graphics properties (i.e. how LyX must use the external file).
> > Despite they're both related to gr
On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote:
> Enrico Forestieri wrote:
> > On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote:
> >
> >> Ok, here with the changes for cygwin, BUT I couldn't test it.
> >
> > And here is the result of my tests. I uninstalled the bakoma f
Mael Hilléreau wrote:
> Well, then the UI is IMO already unintuitive. We have two separate actions:
>
> 1) Edit the external file;
> 2) Edit graphics properties (i.e. how LyX must use the external file).
> Despite they're both related to graphics, these two functionalities are
> clearly distinct.
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
Hi,
Following our middle-mouse pasting discussions, I think I've
implemented the optimal solution that will work under Mac and
Windows too (internally to LyX). My sol
Here is a lyx 1.4.4 one-line file, where two labels have been included.
As i try to insert a cross reference to one label by choosing 'apply' in the
panel, lyx crashes. Choosing 'ok' rather than 'apply' works as expected,
instead
Can anybody reproduced that?
thank you
--
Pol
#LyX 1.4.4 created
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
>> Hi,
>>
>> Following our middle-mouse pasting discussions, I think I've
>> implemented the optimal solution that will work under Mac and
>> Windows too (internally to LyX). My solution is to
Abdelrazak Younes wrote:
Hi,
Following our middle-mouse pasting discussions, I think I've implemented
the optimal solution that will work under Mac and Windows too
(internally to LyX). My solution is to save the selectionBuffer just
before it is pasted in the same LFUN_MOUSE_PRESS. The big ch
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Instead of saveSelection when a selection is formed, this patch
>> saves a selection when it is cleared. This sounds strange so let me
>> explain:
Abdelrazak> Sorry Bo but I think this patch is too complicated and I
Abdelrazak
Hi,
Following our middle-mouse pasting discussions, I think I've implemented
the optimal solution that will work under Mac and Windows too
(internally to LyX). My solution is to save the selectionBuffer just
before it is pasted in the same LFUN_MOUSE_PRESS. The big change is that
we check if
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Peter Kümmel wrote:
>>> 3) In any case, I think that the proper windows way is to use
>>> AddFontResourceEx and, if it returns an error message (win9x), use
>>> AddFontResource instead. There is no need for explicit testing.
>>
>>
Selon Jürgen Spitzmüller <[EMAIL PROTECTED]>:
> Mael Hilléreau wrote:
> > I think that closing the dialog isn't so unexpected, as when you
> > click on the edit button, you know that the focus will go to a new
> > window. I firstly also thought that such a behavior would be
> > surprising, b
> "José" == José Matos <[EMAIL PROTECTED]> writes:
José> I was expecting Jean-Marc opinion on this.
My opinion:
- I do not know what this 'usedtoolbars' thing is. And the comments in
ToolbarBackend.h do not help much. Edwin, is it your doing?
- it seems that the problem was that we need t
To reproduce:
1) Press Cntl-N (start new file)
2) Press Alt-I, I, B (insert TOC from BibTeX)
3) Press Alt-A (Add...)
4) Double Click test
5) Press Alt-O (OK)
6) Press Alt-I C (Insert Citation)
7) Press Alt-A (Add)
LyX now crashes will the following error:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../
On 04.07.2007, at 03:55, Oliver Johns wrote:
I downloaded the lyx 1.5rc2 sources. I followed the INSTALL.MacOSX
instructions carefully. My LDFLAGS are
LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -
framework QuickTime -lz -framework Cocoa
Try adding -liconv to the LDFLAGS
Do
Andreas Neustifter wrote:
On 04.07.2007, at 08:14, Abdelrazak Younes wrote:
Are you sure that this binary version from Andreas contains the patch?
I suspect that it is the straight svn version.
Too bad.
He can't be but I am. I'm positive that it contains your patch from
yesterday, 14:00.
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I see now that the problem applies to keyboard only.
I guess you mean "applies to keyboard _also_"?
AFAICS, saveSelection is only triggered on mouse _release_, not on mouse
motion,
Sure it does. Look at Cursor::selHandle() which is called
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
> On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
>
>> Uwe Stöhr wrote:
>>> > Could you please create a bugzilla (bugzilla.lyx.org) entry and
>>> attach a sample file that
>>> > reproduce the problem?
>>>
>>> There is now b
[EMAIL PROTECTED] wrote:
> Having said that, a preference that allows a user to trade this
> functionality for performance would be fine by me for now.
A preference for switching a bug on? Nah...
Jürgen
Abdelrazak Younes wrote:
> > I see now that the problem applies to keyboard only.
>
> I guess you mean "applies to keyboard _also_"?
AFAICS, saveSelection is only triggered on mouse _release_, not on mouse
motion, so it shouldn't impact performance while selecting.
> > Couldn't we use some kind
[EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
> Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm
On 04.07.2007, at 08:14, Abdelrazak Younes wrote:
Are you sure that this binary version from Andreas contains the
patch? I suspect that it is the straight svn version.
He can't be but I am. I'm positive that it contains your patch from
yesterday, 14:00.
Since my CPU peaks to (almost) 100%
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
> Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
What
On Wed, 4 Jul 2007, Jürgen Spitzmüller wrote:
[EMAIL PROTECTED] wrote:
To be more serious, why should we restrict Windows users from
functionality we appreciate elsewhere?
Please read the whole thread: because the feature isn't implemented
correctly and causes severe performance problems.
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
I don't know the code for this persistent selection, but wouldn't it be
better to save the selection on mouse _release_ only?
I see now that the problem applies to keyboard only.
I guess you mean "applies to keyboard _also_"?
Couldn't we u
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
On Tue, 3 Jul 2007, Jean-Marc Lasgouttes wrote:
> > > > > > "Abdelrazak" == Abdelrazak Younes
> > > > > > <[EMAIL PROTECTED]> writes:
>
> Abdelrazak> Some of those regressions are 'fixedintrunk'.
> Abdelrazak> Unfort
Jürgen Spitzmüller wrote:
> I don't know the code for this persistent selection, but wouldn't it be
> better to save the selection on mouse _release_ only?
I see now that the problem applies to keyboard only. Couldn't we use some kind
of a timer?
Jürgen
[EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2007, Uwe Stöhr wrote:
Could you please test the attached patch? It limits the copied
paragraphs to 10 so the cost of copySelection is constant when
selecting large pieces of texts.
But Georg opposed to this:
http://bugzilla.lyx.org/show_bug.cgi?id=38
[EMAIL PROTECTED] wrote:
On Tue, 3 Jul 2007, Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Some of those regressions are 'fixedintrunk'.
Abdelrazak> Unfortunately, bugzilla does not allow to filter upon two
Abdelrazak> keyboards. One way
[EMAIL PROTECTED] wrote:
> To be more serious, why should we restrict Windows users from
> functionality we appreciate elsewhere?
Please read the whole thread: because the feature isn't implemented correctly
and causes severe performance problems.
Jürgen
Bo Peng wrote:
Analysis:
Previously, any selection action triggers saveSelection, which saves
selection and calls theSelection().haveSelection(cur.selection());.
Therefore, when selecting with page down, saveSelection will be called
many times, with larger and larger selected texts saving to the
82 matches
Mail list logo
