Re: Crashes & selection bug in split view
Le 21/10/2018 à 09:18, Andrew Parsloe a écrit : Since updating to 2.3.1-1 (on windows 7) I am getting sporadic but recurrent crashes -- about 4 now. The message is always I do not see the crash, but I can confirm that when the workarea is split (horizontally or vertically) and one is editing in the second workarea, the display is not updated properly. I have _no_ idea of what is going on, but this can definitely lead to crashes in some cases. If anybody has an idea on why editing is OK in first split but not in second one, please tell me! The situation is not the same when the same file is open in two windows AFAICS. Very very weird. Perhaps it is also relevant that when the view is split into left and right panes, the cursor is placed at the start of the document in the right pane, not at its current position in the left pane. I do not think this is relevant. But indeed this should be fixed. I am not sure how easy it is, though. PS. The emergency save mechanism has been a lifesaver. This is why we release buggy LyX versions :)
Re: Weird Selection Bug
Le 06/09/2016 à 10:33, Helge Hafting a écrit : Den 05. sep. 2016 14:59, skrev Jean-Marc Lasgouttes: Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the position of "the previous mouseclick" to the current mouseclick. So it is OK now, right? Yes, it is ok now. For me, it was ok before too - I see no change. I can only guess that the described problem depends on an OS or a library version that I never used. OK, thnaks. JMarc
Re: Weird Selection Bug
Den 05. sep. 2016 14:59, skrev Jean-Marc Lasgouttes: Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the position of "the previous mouseclick" to the current mouseclick. So it is OK now, right? Yes, it is ok now. For me, it was ok before too - I see no change. I can only guess that the described problem depends on an OS or a library version that I never used. Helge Hafting
Re: Weird Selection Bug
Le 05/09/2016 à 14:56, Helge Hafting a écrit : After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the position of "the previous mouseclick" to the current mouseclick. So it is OK now, right? JMarc
Re: Weird Selection Bug
Den 31. aug. 2016 16:33, skrev Jean-Marc Lasgouttes: Le 31/08/2016 à 11:51, Helge Hafting a écrit : Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Are you sure? I do not see that. I now look at a light blue highlighted selection that goes from the second line to the third. The first line mentioned is not an endpoint - it is forgotten by LyX, and usually by me too. In the meantime, the bug has been fixed in branch and master. If you have access to that, please confirm that it works as it should. After some git trouble*, I compiled & tested. Selection still works as expected with linux & qt5. Selection still goes from the text cursor position to the mouse click position - not from the position of "the previous mouseclick" to the current mouseclick. * I had an old clone of LyX, where I once tested some patches. "git pull" then refused, telling me I needed to "commit my changes" first. But I did not want to commit random experiments into LyX, so I did obviously not commit anything. Various variants of "git --reset" and "git merge --abort" did not persuade git to _drop all changes and just get me the current master_. So I gave up and deleted the entire tree and cloned from scratch. A big waste of bandwith, but faster than figuring out the right git command. :-( Helge Hafting
Re: Weird Selection Bug
Le 31/08/2016 à 11:51, Helge Hafting a écrit : Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Are you sure? I do not see that. I now look at a light blue highlighted selection that goes from the second line to the third. The first line mentioned is not an endpoint - it is forgotten by LyX, and usually by me too. In the meantime, the bug has been fixed in branch and master. If you have access to that, please confirm that it works as it should. JMarc
Re: Weird Selection Bug
Den 23. aug. 2016 12:14, skrev Jean-Marc Lasgouttes: Le 23/08/2016 à 11:25, Helge Hafting a écrit : No! Fortunately, LyX 2.2 on linux behave the way I expect: When I shift-click somewhere, I get a selection from the current text cursor point to the shift-click point. No matter how the text cursor got there. Are you sure? I do not see that. Could it be an OS specific or library version specific issue then? I use LyX 2.2.1, as distributed by arch linux. (64-bit.) Keyboard moves the selection start. (QT 5.7) I also tested LyX 2.1.2 as distributed by debian. Keyboard still moves the selection start. (QT 4.8.6) When I select, I usually drag with the mouse or use shift+arrow keys. So there may have been versions with strange behaviours I never noticed. But in the two versions above, I get what I expect: 1. I type 10 lines of garbage text 2. click on one particular line 3. arrow down (or up or sideways) to some second line 4. shift+click on a third line I now look at a light blue highlighted selection that goes from the second line to the third. The first line mentioned is not an endpoint - it is forgotten by LyX, and usually by me too. Helge Hafting
Re: Weird Selection Bug
Le 23/08/2016 à 18:27, Richard Heck a écrit : If it works, I can backport it, of course. Works here. Fine to backport. Done, thanks. JMarc
Re: Weird Selection Bug
On 08/23/2016 09:54 AM, Jean-Marc Lasgouttes wrote: > Le 23/08/2016 à 12:23, Jean-Marc Lasgouttes a écrit : >> Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : >>> This is indeed a bug. The selection anchor is not reset when moving the >>> cursor with the keyboard. It should be reset just before honoring the >>> Shift-Click, but I am not sure how to do that. >> >> I think it is fixed in master now. Please test. > > I it works, I can backport it, of course. Works here. Fine to backport. Richard
Re: Weird Selection Bug
Le 23/08/2016 à 12:23, Jean-Marc Lasgouttes a écrit : Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : This is indeed a bug. The selection anchor is not reset when moving the cursor with the keyboard. It should be reset just before honoring the Shift-Click, but I am not sure how to do that. I think it is fixed in master now. Please test. I it works, I can backport it, of course. JMarc
Re: Weird Selection Bug
Le 23/08/2016 à 12:14, Jean-Marc Lasgouttes a écrit : This is indeed a bug. The selection anchor is not reset when moving the cursor with the keyboard. It should be reset just before honoring the Shift-Click, but I am not sure how to do that. I think it is fixed in master now. Please test. JMarc
Re: Weird Selection Bug
Le 23/08/2016 à 11:25, Helge Hafting a écrit : No! Fortunately, LyX 2.2 on linux behave the way I expect: When I shift-click somewhere, I get a selection from the current text cursor point to the shift-click point. No matter how the text cursor got there. Are you sure? I do not see that. Seriously, people move the cursor around by mouse and by keyboard. When they need to select, they surely don't consider *how* the cursor was moved? This is indeed a bug. The selection anchor is not reset when moving the cursor with the keyboard. It should be reset just before honoring the Shift-Click, but I am not sure how to do that. JMarc
Re: Weird Selection Bug
Den 02. aug. 2016 08:11, skrev Kornel Benko: Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: Click somewhere with the mouse. Now move the cursor with the keyboard. Then shift-click to select. The selection will begin (or end) where you had previously clicked with the mouse, not where you had moved the cursor with the keyboard. I can reproduce with Qt 4 and Qt 5 and back to LyX 2.1.0. Scott I can reproduce too, but I think, it is the correct behaviour. Using the up/down keys which resets the selection start does not feel right IMHO. No! Fortunately, LyX 2.2 on linux behave the way I expect: When I shift-click somewhere, I get a selection from the current text cursor point to the shift-click point. No matter how the text cursor got there. Seriously, people move the cursor around by mouse and by keyboard. When they need to select, they surely don't consider *how* the cursor was moved? LyX place no marker at "the last click location", having a selection go from there seems weird. Also consider that the "last click" may be far away - I can type for many minutes without using the mouse at all. My hands are at the keyboard when I write text, so cursor movements are mostly done with arrow keys and pageup/down. Some people uses the mouse more - but that is individual, and depending on whether you type new stuff or just move around touching up. Now, the mouse is fine for making selections. but if they cursor already is correctly placed at one end, I see no need to click the same location so the "location of the last click" also is in the same place. The location of the last click may have scrolled off screen, it may have been cut, erased or moved around . . . Other GUI sw (thunderbird etc.) that moves the cursor when clicking, also uses the cursor position regardless of how the cursor got there. xterm is the only I have seen that cares about "the location of last click", but xterm does not position the cursor upon mouse clicks and so is very different. Helge Hafting
Re: Weird Selection Bug
Le 02/08/2016 à 07:39, Stephan Witt a écrit : OTOH starting the selection at the current cursor position after moving the input focus with keyboard is the way it works on Mac - with LyX and with other text editors. +1, not just on Mac
Re: Weird Selection Bug
Am 02.08.2016 um 08:11 schrieb Kornel Benko : > > Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak > >> On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: >>> Click somewhere with the mouse. Now move the cursor with the keyboard. >>> Then shift-click to select. The selection will begin (or end) where you >>> had previously clicked with the mouse, not where you had moved the >>> cursor with the keyboard. >> >> I can reproduce with Qt 4 and Qt 5 and back to LyX 2.1.0. >> >> Scott > > I can reproduce too, but I think, it is the correct behaviour. Using the > up/down keys which > resets the selection start does not feel right IMHO. OTOH starting the selection at the current cursor position after moving the input focus with keyboard is the way it works on Mac - with LyX and with other text editors. Stephan
Re: Weird Selection Bug
Am Dienstag, 2. August 2016 um 01:24:38, schrieb Scott Kostyshak > On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: > > Click somewhere with the mouse. Now move the cursor with the keyboard. > > Then shift-click to select. The selection will begin (or end) where you > > had previously clicked with the mouse, not where you had moved the > > cursor with the keyboard. > > I can reproduce with Qt 4 and Qt 5 and back to LyX 2.1.0. > > Scott I can reproduce too, but I think, it is the correct behaviour. Using the up/down keys which resets the selection start does not feel right IMHO. Kornel signature.asc Description: This is a digitally signed message part.
Re: Weird Selection Bug
On Mon, Aug 01, 2016 at 11:50:52AM -0400, Richard Heck wrote: > Click somewhere with the mouse. Now move the cursor with the keyboard. > Then shift-click to select. The selection will begin (or end) where you > had previously clicked with the mouse, not where you had moved the > cursor with the keyboard. I can reproduce with Qt 4 and Qt 5 and back to LyX 2.1.0. Scott signature.asc Description: PGP signature
Weird Selection Bug
Click somewhere with the mouse. Now move the cursor with the keyboard. Then shift-click to select. The selection will begin (or end) where you had previously clicked with the mouse, not where you had moved the cursor with the keyboard. Richard
Re: Viewer Selection Bug
On 10/16/2009 12:18 PM, rgheck wrote: On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. *Sigh*. Seems I repeat my faults: http://marc.info/?l=lyx-devel&m=124345121717776&w=2 I now see how it was changed last time and will try changing it the same way. rh
Re: Viewer Selection Bug
On 10/16/2009 11:28 AM, Jürgen Spitzmüller wrote: rgheck wrote: In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. *Sigh*. Seems I repeat my faults: http://marc.info/?l=lyx-devel&m=124345121717776&w=2 I do not have time now, but if no one beats me to it, I will have a look eventually. What is actually happening is that the list of alternatives is being added again every time you save the preferences file. I had a quick look at this and I'm very confused. I don't even see where any of this is actually happening, since the PrefFileFormats::apply() routine doesn't do very much. So if you could give me a pointer There was another bug that viewer and editor selections weren't being saved. I've committed what I think is a fix for that. You might want to check I've done the right thing. Richard
Re: Viewer Selection Bug
rgheck wrote: > In trunk, I seem to have a billion converters listed for DVI. The > billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort > of thing for PDF. I think what's likely happening is that things are > being added each time I reconfigure. *Sigh*. Seems I repeat my faults: http://marc.info/?l=lyx-devel&m=124345121717776&w=2 I do not have time now, but if no one beats me to it, I will have a look eventually. Jürgen
Viewer Selection Bug
In trunk, I seem to have a billion converters listed for DVI. The billion read: xdvi, okular, xdvi, okular, xdvi, okular, etc. Same sort of thing for PDF. I think what's likely happening is that things are being added each time I reconfigure. Richard
Re: Selection without a selection [Bug 5162]
JMarc already mentioned it and I already apologized for disrespecting the style. Do not worry, I do not think André is expecting an apoolgy, although one never knows what he might be up to... JMarc
RE: Selection without a selection [Bug 5162]
> Incidentally, if you want to have your patches easy to apply please
> stick to the LyX coding conventions as outlined in
> development/coding/{Rules,Recommendations}
>
> Andre'
JMarc already mentioned it and I already apologized for
disrespecting the style.
The patches within that e-mail weren't really supposed to
be committed right away. I was just sharing ideas and
expressing my opinion about the problem we were working
on.
I'm not that familiarized with the style yet, so I might be a
bit sloppy while 'wrestling' with the code.
Vincent
Re: Selection without a selection [Bug 5162]
On Thu, Aug 14, 2008 at 12:09:39PM +0200, Vincent van Ravesteijn - TNW wrote:
> Index: src/insets/InsetCollapsable.cpp
> ===
> --- src/insets/InsetCollapsable.cpp (revision 26147)
> +++ src/insets/InsetCollapsable.cpp (working copy)
> @@ -495,7 +504,14 @@
> case mouse_button::button3:
> // Pass the command to the enclosing
> InsetText,
> // so that the cursor gets set.
> - cur.undispatched();
> + if( cur.bv().cursor().isInside( this ) )
> + {
> + cur.noUpdate();
> + }
> + else
> + {
> + cur.undispatched();
> + }
> break;
Incidentally, if you want to have your patches easy to apply please
stick to the LyX coding conventions as outlined in
development/coding/{Rules,Recommendations}
Andre'
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Sorry for the style, I wasn't too sure about that piece of code, so I > lacked being precise. Normally I'm careful to adjust to the rest of the > code. That is OK, I am just preparing to be able to directly apply your patches in the future :) > By the way, when generating patches with svn diff, I'm getting a lot of > changes at lines I didn't edit and which looks the same before and > after. This occurs probably due to the fact that I'm working on Windows > most of the time. Do you know a way to prevent this ? Could it be that the editor removes spaces at the end of lines? Or that it changes tabs with spaces? JMarc
RE: Selection without a selection [Bug 5162]
> The behaviour of these inset-related functions (toggle, dissolve, > settings) is supposed to be: > > 1/ if there is a inset at cursor, try the function on it > > 2/ if there is no inset or the function failed try on the enclosing inset. > > Does it make sense? > > It is one reason why the cursor shall be set before popping the context menu... It makes sense *iff* the cursor is always set before popping the context menu, but I'd advocate not always to do this (as I wrote before). I'll think about this. > In general, try to produce code that looks like the rest of the code (or read the stuff in development/coding/). Sorry for the style, I wasn't too sure about that piece of code, so I lacked being precise. Normally I'm careful to adjust to the rest of the code. By the way, when generating patches with svn diff, I'm getting a lot of changes at lines I didn't edit and which looks the same before and after. This occurs probably due to the fact that I'm working on Windows most of the time. Do you know a way to prevent this ?
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Then, I altered the InsetNote code to give a context-edit menu when you > right-click the text-part and a context-note menu when you right-click > the button. This code is probably useful for all InsetCollapsables, so > this code has to be moved to that class. Yes, I think something like that makes sense in InsetCollapsable, but it needs tweaking. JMarc
Re: Selection without a selection [Bug 5162]
[and now try to answer the annoying one :)]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> About the dissolve inset items and stuff. I added this to the code and
> it solves the problem (a bit), but I have to try and figure out what the
> exact behaviour is. It is more or less copied from the inset-settings
> code.
The behaviour of these inset-related functions (toggle, dissolve,
settings) is supposed to be:
1/ if there is a inset at cursor, try the function on it
2/ if there is no inset or the function failed try on the enclosing inset.
Does it make sense?
> If I understand correctly, LyX is designed such that you can always
> enter a lfun into the program bar. As a consequence, the inset-dissolve
> LFUN only has information about where the cursor is, not about where the
> user clicked. Thus, if you have a nested inset with the cursor right in
> front of the inset and you right-click the button of any of the two
> insets, it is practically impossible for the inset-dissolve code to know
> which button was clicked. Unless cur or cur.bv().cursor() points to the
> button that was clicked. Please help me with this?
It is one reason why the cursor shall be set before popping the
context menu...
Some remarks about style:
> Index: src/Text3.cpp
> ===
> --- src/Text3.cpp (revision 26147)
> +++ src/Text3.cpp (working copy)
> @@ -2103,6 +2105,14 @@
> } else {
> enable = !isMainText(cur.bv().buffer())
>&& cur.inset().nargs() == 1;
> + if( !enable )
no spaces please
> + {
put that on the line of the if().
In general, try to produce code that looks like the rest of the code
(or read the stuff in development/coding/).
JMarc
Re: Selection without a selection [Bug 5162]
[still replying separately to the different chunks...] "Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Last, Jmarc: you changed the code below, but I think you should only > update the cursor position when the current cursor position is outside > the Inset. Otherwise when you are editing an Inset, you want to alter > the Inset in any way by right-clicking the button, LyX will move your > cursor outside the Inset. This is clearly not what you want. I am not sure the code is prepared to pop a context menu at a place different from where the cursor is. I think it was the reason of some of our past problems. A better solution might be to always prepend the button-menu of the inset to the normal context edit menu, do that people do not need to press the menu button. JMarc
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > The folowing patch will solve the problem of bug 5156 discussed before. > Selecting the character at position 6 gives a selectionEnd at pos 7 and > a selectionBegin at pos 6. Checking for the current selection using <= > and >= always results in two characters being marked as selection. This > is wrong, so I changed <= into <. This probably is the case at a lot > more places in the code. I applied it. JMarc
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: >> //If there is a selection, return the containing inset menu >> 537 if (d->cursor_.selection()) >> 538 return d->cursor_.inset().contextMenu(*this, x, > y); > > Is it now ensured that you click on the selection and not outside the > selection ? Yes, because if you click outside of the selection, if will have been reset at MOUSE_PRESS time (the code you point out below). > The folowing patch will solve the problem of bug 5156 discussed before. > Selecting the character at position 6 gives a selectionEnd at pos 7 and > a selectionBegin at pos 6. Checking for the current selection using <= > and >= always results in two characters being marked as selection. This > is wrong, so I changed <= into <. This probably is the case at a lot > more places in the code. It is my fault. I pondered using the correct test, actually :) But I thought being a bit more lenient would be nice... If one clicks on the second half of the last character of the selection (visually in the selection itself), it will reset it... JMarc
RE: Selection without a selection [Bug 5162]
> //If there is a selection, return the containing inset menu
> 537 if (d->cursor_.selection())
> 538 return d->cursor_.inset().contextMenu(*this, x,
y);
Is it now ensured that you click on the selection and not outside the
selection ?
The folowing patch will solve the problem of bug 5156 discussed before.
Selecting the character at position 6 gives a selectionEnd at pos 7 and
a selectionBegin at pos 6. Checking for the current selection using <=
and >= always results in two characters being marked as selection. This
is wrong, so I changed <= into <. This probably is the case at a lot
more places in the code.
Index: src/Text3.cpp
===
--- src/Text3.cpp (revision 26147)
+++ src/Text3.cpp (working copy)
@@ -1184,7 +1185,7 @@
// Don't do anything if we right-click a
// selection, a context menu will popup.
if (bvcur.selection() && cur >=
bvcur.selectionBegin()
- && cur <= bvcur.selectionEnd()) {
+ && cur < bvcur.selectionEnd()) {
cur.noUpdate();
return;
About the dissolve inset items and stuff. I added this to the code and
it solves the problem (a bit), but I have to try and figure out what the
exact behaviour is. It is more or less copied from the inset-settings
code.
If I understand correctly, LyX is designed such that you can always
enter a lfun into the program bar. As a consequence, the inset-dissolve
LFUN only has information about where the cursor is, not about where the
user clicked. Thus, if you have a nested inset with the cursor right in
front of the inset and you right-click the button of any of the two
insets, it is practically impossible for the inset-dissolve code to know
which button was clicked. Unless cur or cur.bv().cursor() points to the
button that was clicked. Please help me with this?
Index: src/Text3.cpp
===
--- src/Text3.cpp (revision 26147)
+++ src/Text3.cpp (working copy)
@@ -2103,6 +2105,14 @@
} else {
enable = !isMainText(cur.bv().buffer())
&& cur.inset().nargs() == 1;
+ if( !enable )
+ {
+ Inset * next_inset = cur.nextInset();
+ if (next_inset) {
+ enable = next_inset->nargs() ==
1;
+ }
+ }
+
}
break;
Then, I altered the InsetNote code to give a context-edit menu when you
right-click the text-part and a context-note menu when you right-click
the button. This code is probably useful for all InsetCollapsables, so
this code has to be moved to that class.
Index: src/insets/InsetNote.cpp
===
--- src/insets/InsetNote.cpp(revision 26147)
+++ src/insets/InsetNote.cpp(working copy)
@@ -339,9 +339,12 @@
}
-docstring InsetNote::contextMenu(BufferView const &, int, int) const
+docstring InsetNote::contextMenu(BufferView const &, int x, int y)
const
{
- return from_ascii("context-note");
+ if( hitButton(x, y) )
+ return from_ascii("context-note");
+ else
+ return from_ascii("context-edit");
}
Last, Jmarc: you changed the code below, but I think you should only
update the cursor position when the current cursor position is outside
the Inset. Otherwise when you are editing an Inset, you want to alter
the Inset in any way by right-clicking the button, LyX will move your
cursor outside the Inset. This is clearly not what you want.
Index: src/insets/InsetCollapsable.cpp
===
--- src/insets/InsetCollapsable.cpp (revision 26147)
+++ src/insets/InsetCollapsable.cpp (working copy)
@@ -495,7 +504,14 @@
case mouse_button::button3:
// Pass the command to the enclosing
InsetText,
// so that the cursor gets set.
- cur.undispatched();
+ if( cur.bv().cursor().isInside( this ) )
+ {
+ cur.noUpdate();
+ }
+ else
+ {
+ cur.undispatched();
+ }
break;
case mouse_button::none:
case mouse_button::button2:
RE: Selection without a selection [Bug 5162]
-- Ignore the previous mail, send by accident --
RE: Selection without a selection [Bug 5162]
> Try again. Now, when there is a selection, the context menu is always
> the one of the inset containing the selection.
//If there is a selection, return the containing inset menu
537 if (d->cursor_.selection())
538 return d->cursor_.inset().contextMenu(*this, x,
y);
> If you right-click the button of the Note, the dissolve item is always
> disabled. Related to this: choosing the dissolve item of the context
> menu of a subfloat will dissolve the outer float. Probably caused by
> an inset-dissolve command instead of a next-inset-dissolve command. (I
> know there has been discussion on this point before).
This patch will solve the problem of bug 5156 discussed before.
Selecting the character at position 6 gives a selectionEnd at pos 7 and
a selectionBegin at pos 6. Checking for the current selection using <=
and >= always results in two characters being marked as selection. This
is wrong, so I changed <= into <. This probably is the case at a lot
more places in the code.
Index: src/Text3.cpp
===
--- src/Text3.cpp (revision 26147)
+++ src/Text3.cpp (working copy)
@@ -1184,7 +1185,7 @@
// Don't do anything if we right-click a
// selection, a context menu will popup.
if (bvcur.selection() && cur >=
bvcur.selectionBegin()
- && cur <= bvcur.selectionEnd()) {
+ && cur < bvcur.selectionEnd()) {
cur.noUpdate();
return;
About the dissolve inset items and stuff. I added this to the code and
it solves the problem (a bit), but I have to try what the exact
behaviour is.
@@ -2103,6 +2105,14 @@
} else {
enable = !isMainText(cur.bv().buffer())
&& cur.inset().nargs() == 1;
+ if( !enable )
+ {
+ Inset * next_inset = cur.nextInset();
+ if (next_inset) {
+ enable = next_inset->nargs() ==
1;
+ }
+ }
+
}
break;
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > What is the wanted behaviour for right-clicking inside the insets. > Right-clicking inside a Float will open the edit context menu, while > right-clicking inside a Note, ERT, Box, ... will open the context > menu of the inset. > > I think that you'd expect an edit context menu if you right-click on > text (especially selected text). If you think so too, then the > dilemma pops up for the ERT as it does not have a box anymore. So > close/dissolve should be added to the edit menu. Yes, I think there is a lack of design in this area. Note that is it possible to add close/dissolve to the menu as OptItem, so that they do not show in the main context menu. Do you think you could have a go at that? JMarc
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > Enter some text and insert a Note (without a space in between). When you > select text in front of and adjacent to the Note, right-clicking the > button of the Note won't clear the selection. This means that when the > cursor is not immediately in front of the Note a context menu will be > shown with all items disabled. (And bug 5156 still occurs) Try again. Now, when there is a selection, the context menu is always the one of the inset containing the selection. > If you right-click the button of the Note, the dissolve item is always > disabled. Related to this: choosing the dissolve item of the context > menu of a subfloat will dissolve the outer float. Probably caused by an > inset-dissolve command instead of a next-inset-dissolve command. (I know > there has been discussion on this point before). Yes, this part is a mess. JMarc
RE: Selection without a selection [Bug 5162]
Hi, What is the wanted behaviour for right-clicking inside the insets. Right-clicking inside a Float will open the edit context menu, while right-clicking inside a Note, ERT, Box, ... will open the context menu of the inset. I think that you'd expect an edit context menu if you right-click on text (especially selected text). If you think so too, then the dilemma pops up for the ERT as it does not have a box anymore. So close/dissolve should be added to the edit menu. What do you think ? Vincent
Re: Selection without a selection [Bug 5162]
Vincent van Ravesteijn - TNW wrote: Could you try again and tell me what problems remain? Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a space in between). When you select text in front of and adjacent to the Note, right-clicking the button of the Note won't clear the selection. This means that when the cursor is not immediately in front of the Note a context menu will be shown with all items disabled. (And bug 5156 still occurs) Right. JMarc: You have to start with the cursor immediately before the note, then select (say) a word back, so the anchor remains right before the note. Then the selection is note cleared, and the context menu is greyed out. This is also true if the selection includes the inset. Probably that is the cause in the first case, too: The anchor includes the inset's metacharacter. 3. If you right-click the button of the Note, the dissolve item is always disabled. Confirmed, even if the cursor is in the inset. rh
RE: Selection without a selection [Bug 5162]
>Could you try again and tell me what problems remain? > >Jmarc 1. As a consequence of second point below, Bug 5156 still leads to an assertion (crash). Furthermore, some (minor) problems remain: 2. Enter some text and insert a Note (without a space in between). When you select text in front of and adjacent to the Note, right-clicking the button of the Note won't clear the selection. This means that when the cursor is not immediately in front of the Note a context menu will be shown with all items disabled. (And bug 5156 still occurs) 3. If you right-click the button of the Note, the dissolve item is always disabled. Related to this: choosing the dissolve item of the context menu of a subfloat will dissolve the outer float. Probably caused by an inset-dissolve command instead of a next-inset-dissolve command. (I know there has been discussion on this point before). 4. When selecting both the text and the Note and right-clicking on the Note shows a context menu of the Note with all items disabled instead of the normal edit context menu, which you would expect when right-clicking on a selection. Only when the cursor is immediately in front of the Note, the context menu will have some enabled items. Vincent
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > So, > - There is a bug which causes that when filling the context-menu it > looks at the cursor position in stead of the position of the > right-click. I think it is fixed now. > - and a bug that when right-clicking outside a selection, the selection > should is not cleared and the cursor is at the wrong position. I am not sure I parse the 'should is not' part... Could you try again and tell me what problems remain? JMarc
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > I already added a sort of a 'patch' to the bug in bugzilla, which looks > like to solve the problem. It calls the function Cursor::setSelection(). > > Although the name is not really describing what it does, a comment > inside this function exactly describes the problem at hand. So, at least > someone has thought about this before. I applied the patch. JMarc
RE: Selection without a selection [Bug 5162]
>> For example: right-clicking on a Note while the cursor is inside >> another Note. Without knowing about this bug, you never know which >> Note will be changed into 'Greyed Out' if you choose this on the context menu. > >But this is a completely different bug, right? Probably introduced by me, BTW. > >Jmarc Yes, it is a different bug, but it is solved with the same patch. If you have a Note and an ERT. Put the cursor inside the ERT and right-click on the Note. Then the context menu of the Note is shown, but none of the items is checked. This is because it asks the ERT about which type of Note it is, because it still is the inset at the place of the cursor (probably also the cause of bug 5156) The normal behaviour however would be to put the cursor at the place of the right-click, before creating the context-menu. However, this doesn't happen when there is a selection and this is exactly the bug we are discussing. If a user does make a real selection, then this selection should be cleared whenever he right-clicks outside the selected area, moving the cursor to the new position. There is a recent fix regarding this subject, which makes sure that the selection is not cleared when right-clicking. Does this take into account whether it is right-clicked inside the selection or not ? So, - There is a bug which causes that when filling the context-menu it looks at the cursor position in stead of the position of the right-click. - and a bug that when right-clicking outside a selection, the selection should is not cleared and the cursor is at the wrong position. If the second bug is solved, the first bug will disappear also, because the cursor position is then always the same as the position of the right-click. Moreover, bug 5156 will probably also disappear. (sorry for the non-conciseness) Vincent
Re: Selection without a selection [Bug 5162]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> For example: right-clicking on a Note while the cursor is inside another >> Note. Without knowing about this bug, you never know which Note will be >> changed into 'Greyed Out' if you choose this on the context menu. > > But this is a completely different bug, right? Probably introduced by > me, BTW. And fixed right now. JMarc
Re: Selection without a selection [Bug 5162]
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > I already added a sort of a 'patch' to the bug in bugzilla, which looks > like to solve the problem. It calls the function Cursor::setSelection(). The patch makes sense actually. You should even remove the 'selection() = true' statement above. > For example: right-clicking on a Note while the cursor is inside another > Note. Without knowing about this bug, you never know which Note will be > changed into 'Greyed Out' if you choose this on the context menu. But this is a completely different bug, right? Probably introduced by me, BTW. JMarc
RE: Selection without a selection [Bug 5162]
I already added a sort of a 'patch' to the bug in bugzilla, which looks like to solve the problem. It calls the function Cursor::setSelection(). Although the name is not really describing what it does, a comment inside this function exactly describes the problem at hand. So, at least someone has thought about this before. Moreover, this bug is the reason that right-clicking on an inset leads to strange things. For example: right-clicking on a Note while the cursor is inside another Note. Without knowing about this bug, you never know which Note will be changed into 'Greyed Out' if you choose this on the context menu. Vincent -Original Message- From: rgheck [mailto:[EMAIL PROTECTED] Sent: woensdag 13 augustus 2008 16:34 To: Vincent van Ravesteijn - TNW Cc: lyx-devel@lists.lyx.org Subject: Re: Selection without a selection [Bug 5162] Vincent van Ravesteijn - TNW wrote: > I was trying to figure out why it is *always* a surprise whether LyX > moves the cursor when right-clicking somewhere or not. It seems to be > that if you click somewhere and you hold the mouse down and you move > your mouse, LyX will select text, for instance. However, if you move > the mouse just a little (less than a character) you do not select > anything, but the Edit->Cut and Edit->Copy are enabled. > > Yes, I see that too. Very odd. rh
Re: Selection without a selection [Bug 5162]
rgheck <[EMAIL PROTECTED]> writes: > Vincent van Ravesteijn - TNW wrote: >> I was trying to figure out why it is *always* a surprise whether LyX >> moves the cursor when right-clicking somewhere or not. It seems to be >> that if you click somewhere and you hold the mouse down and you move >> your mouse, LyX will select text, for instance. However, if you move the >> mouse just a little (less than a character) you do not select anything, >> but the Edit->Cut and Edit->Copy are enabled. > Yes, I see that too. Very odd. Not so odd, considering that LFUN_MOUSE_MOTION sets cursor.selection() to true, indicating that selection is in progress. However, such a selection does not make sense when cursor and anchor are at the same place. I am not sure what is the best way to handle that, unfortunately. JMarc
Re: Selection without a selection [Bug 5162]
Vincent van Ravesteijn - TNW wrote: I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance. However, if you move the mouse just a little (less than a character) you do not select anything, but the Edit->Cut and Edit->Copy are enabled. Yes, I see that too. Very odd. rh
Selection without a selection [Bug 5162]
I was trying to figure out why it is *always* a surprise whether LyX moves the cursor when right-clicking somewhere or not. It seems to be that if you click somewhere and you hold the mouse down and you move your mouse, LyX will select text, for instance. However, if you move the mouse just a little (less than a character) you do not select anything, but the Edit->Cut and Edit->Copy are enabled. If you now right-click somewhere, LyX won't update the cursor, because it is programmed not to anything when there is a selection. I think this would fix a lot of frustration! Vincent
Re: Mouse Selection Bug Again
Richard Heck <[EMAIL PROTECTED]> writes: > Here's what I think is happening. Selecting some text in one konsole > app is clearing the selected text in the other, so a SelectionClear > event is being triggered. Presumably, this is going to ALL aware > applications, and that would include the konsole app itself, right? So > maybe the event to which we're responding is one we triggered > ourselves. But how do we know that? Andre is said to have a nice message explaining why we have selection problems, but he is not able to send mail because of firewall problems (this is why he is so silent). Hopefully he will eventually send it. I do not have a good intuition about this myself. JMarc
Re: Mouse Selection Bug Again
Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: This depends. Selecting in Firefox clears the selection in Konsole, but not vice versa. Firefox has obviously chosen to ignore the SelectionClear event, and I'd propose we should do the same. Why should selecting in Firefox clear my carefully made selection in LyX? Because then, when you paste in konsole you cannot predict whether the string will come from firefox or lyx? But that's not true---or, perhaps, we're talking past each other. I would expect the one I pasted to be the last one I copied, and that's what happens if I select text in Firefox and Thunderbird, both of which are ignoring the SelectionClear events that X is apparently sending. What I'm talking about is simply highlighting---selecting, in that sense, not also copying. So if you highlight some text in one konsole window and then highlight some more text in another, the highlight in the first vanishes. But the clipboard doesn't change---it doesn't affect what gets pasted. Here's what I think is happening. Selecting some text in one konsole app is clearing the selected text in the other, so a SelectionClear event is being triggered. Presumably, this is going to ALL aware applications, and that would include the konsole app itself, right? So maybe the event to which we're responding is one we triggered ourselves. But how do we know that? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Mouse Selection Bug Again
Richard Heck <[EMAIL PROTECTED]> writes: > This depends. Selecting in Firefox clears the selection in Konsole, > but not vice versa. Firefox has obviously chosen to ignore the > SelectionClear event, and I'd propose we should do the same. Why > should selecting in Firefox clear my carefully made selection in LyX? Because then, when you paste in konsole you cannot predict whether the string will come from firefox or lyx? JMarc
Re: Mouse Selection Bug Again
Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: I've just locally disabled any reaction to SelectionClear events in GuiApplication::x11EventFilter(). I don't see any ill effects, and it obviously makes the bug go away. Do we want X clearing the selection for us, anyway? Who's the X expert around here? The idea is that only one application should have the selection at the same time. If you open two terminal windows (or one terminal and one firefox), you will see that it is not possible to have a selection in the two at the same time. This depends. Selecting in Firefox clears the selection in Konsole, but not vice versa. Firefox has obviously chosen to ignore the SelectionClear event, and I'd propose we should do the same. Why should selecting in Firefox clear my carefully made selection in LyX? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Mouse Selection Bug Again
Richard Heck <[EMAIL PROTECTED]> writes: > I've just locally disabled any reaction to SelectionClear events in > GuiApplication::x11EventFilter(). I don't see any ill effects, and it > obviously makes the bug go away. Do we want X clearing the selection > for us, anyway? Who's the X expert around here? The idea is that only one application should have the selection at the same time. If you open two terminal windows (or one terminal and one firefox), you will see that it is not possible to have a selection in the two at the same time. The question is probably to know why you get those selectionClear events. JMarc
Re: Mouse Selection Bug Again
I've just locally disabled any reaction to SelectionClear events in
GuiApplication::x11EventFilter(). I don't see any ill effects, and it
obviously makes the bug go away. Do we want X clearing the selection for
us, anyway? Who's the X expert around here?
Here's the patch for reference:
Index: GuiApplication.cpp
===
--- GuiApplication.cpp (revision 19390)
+++ GuiApplication.cpp (working copy)
@@ -321,10 +321,9 @@
if (!currentView())
return false;
- switch (xev->type) {
- case SelectionRequest: {
+ if (xev->type == SelectionRequest) {
if (xev->xselectionrequest.selection != XA_PRIMARY)
- break;
+ return false;
LYXERR(Debug::GUI) << "X requested selection." << endl;
BufferView * bv = currentView()->view();
if (bv) {
@@ -332,18 +331,7 @@
if (!sel.empty())
selection_.put(sel);
}
- break;
}
- case SelectionClear: {
- if (xev->xselectionclear.selection != XA_PRIMARY)
- break;
- LYXERR(Debug::GUI) << "Lost selection." << endl;
- BufferView * bv = currentView()->view();
- if (bv)
- bv->clearSelection();
- break;
- }
- }
return false;
}
#endif
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Mouse Selection Bug Again
Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? No, just a slew of "X requested selection" followed by "Lost selection", these being output from GuiApplication::x11EventFilter(). The question to me is why X is sending a SelectionClear even in the first place. I'm just moving the mouse. Qt is forwarding these, right? Could this just be a Qt bug? It seems to me that the event may be generated by Qt. The framestack seems to show the X SelectionRequest events being generated by QApplication::isEffectEnabled, though I don't see this in the code. Still, every time, the top of the stack is x11ProcessEvent calling isEffectEnabled calling x11EventFilter. There aren't threads here, are there? gdb just identifies one. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Mouse Selection Bug Again
Richard Heck <[EMAIL PROTECTED]> writes: > Does it make any sense that selecting with the RIGHT mouse button seems OK? Not to me. If you put all debug on, do you see something interesting when the selection disappears? JMarc
Re: Mouse Selection Bug Again
Jean-Marc Lasgouttes wrote: Richard Heck <[EMAIL PROTECTED]> writes: Well, I don't understand what's going on here really, but I do know roughly why the selection is occasionally being cleared (and I am seeing this with 1.6svn as well as with 1.5.2svn): Movement of the mouse is occasionally causing a SelectionClear even to be passed into GuiApplication::x11EventFilter, which is calling BufferView::clearSelection(). I don't know why this event is appearing, as it's just mouse movement that's going on here. Stab in the dark: does this patch help? Sadly, no. Does it make any sense that selecting with the RIGHT mouse button seems OK? JMarc svndiff src Index: src/BufferView.cpp === --- src/BufferView.cpp (révision 19396) +++ src/BufferView.cpp (copie de travail) @@ -1227,7 +1227,8 @@ bool BufferView::workAreaDispatch(FuncRe cur.dispatch(cmd); //Do we have a selection? - theSelection().haveSelection(cursor().selection()); + if (cur.result().dispatched()) + theSelection().haveSelection(cursor().selection()); // Redraw if requested and necessary. if (cur.result().dispatched() && cur.result().update()) -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Mouse Selection Bug Again
Richard Heck <[EMAIL PROTECTED]> writes: > Well, I don't understand what's going on here really, but I do know > roughly why the selection is occasionally being cleared (and I am > seeing this with 1.6svn as well as with 1.5.2svn): Movement of the > mouse is occasionally causing a SelectionClear even to be passed into > GuiApplication::x11EventFilter, which is calling > BufferView::clearSelection(). I don't know why this event is > appearing, as it's just mouse movement that's going on here. Stab in the dark: does this patch help? JMarc svndiff src Index: src/BufferView.cpp === --- src/BufferView.cpp (révision 19396) +++ src/BufferView.cpp (copie de travail) @@ -1227,7 +1227,8 @@ bool BufferView::workAreaDispatch(FuncRe cur.dispatch(cmd); //Do we have a selection? - theSelection().haveSelection(cursor().selection()); + if (cur.result().dispatched()) + theSelection().haveSelection(cursor().selection()); // Redraw if requested and necessary. if (cur.result().dispatched() && cur.result().update())
Mouse Selection Bug Again
Well, I don't understand what's going on here really, but I do know roughly why the selection is occasionally being cleared (and I am seeing this with 1.6svn as well as with 1.5.2svn): Movement of the mouse is occasionally causing a SelectionClear even to be passed into GuiApplication::x11EventFilter, which is calling BufferView::clearSelection(). I don't know why this event is appearing, as it's just mouse movement that's going on here. Here's the framestack at that point (and this is pretty consistent): #0 lyx::frontend::GuiApplication::x11EventFilter (this=0x9c3e218, xev=0xbfbdd1e8) at GuiApplication.cpp:343 #1 0x062f7cbe in QApplication::isEffectEnabled () at ../../boost/boost/regex/v4/match_results.hpp:125 #2 0x063034f5 in QApplication::x11ProcessEvent () at ../../boost/boost/regex/v4/match_results.hpp:125 #3 0x063281d4 in QX11Info::copyX11Data () at ../../boost/boost/regex/v4/match_results.hpp:125 #4 0x00bc0442 in g_main_context_dispatch () at ../../boost/boost/regex/v4/match_results.hpp:125 #5 0x00bc341f in g_main_context_check () at ../../boost/boost/regex/v4/match_results.hpp:125 #6 0x00bc3985 in g_main_context_iteration () at ../../boost/boost/regex/v4/match_results.hpp:125 #7 0x0026b7f8 in QEventDispatcherGlib::processEvents () at ../../boost/boost/regex/v4/match_results.hpp:125 #8 0x06327f85 in QX11Info::copyX11Data () at ../../boost/boost/regex/v4/match_results.hpp:125 #9 0x00249911 in QEventLoop::processEvents () at ../../boost/boost/regex/v4/match_results.hpp:125 #10 0x00249a1c in QEventLoop::exec () at ../../boost/boost/regex/v4/match_results.hpp:125 #11 0x0024bdda in QCoreApplication::exec () at ../../boost/boost/regex/v4/match_results.hpp:125 #12 0x062aef37 in QApplication::exec () at ../../boost/boost/regex/v4/match_results.hpp:125 #13 0x086f230a in lyx::frontend::GuiApplication::exec (this=0x9c3e218) at GuiApplication.cpp:168 #14 0x082d03da in lyx::LyX::exec (this=0xbfbdde7c, [EMAIL PROTECTED], argv=0xbfbddf34) at LyX.cpp:482 #15 0x080692ae in main (argc=1, argv=Cannot access memory at address 0x4 ) at main.cpp:48 -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] fix caption inset selection bug
Martin Vermeer wrote: On Tue, Feb 06, 2007 at 10:57:23AM +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: It is this simple (I think). (The inset API has its nice sides) Thanks for helping me at this. Abdel. OK. Could you commit it? I'll do it. Abdel.
Re: [Patch] fix caption inset selection bug
On Tue, Feb 06, 2007 at 10:57:23AM +0100, Abdelrazak Younes wrote: > Martin Vermeer wrote: > >It is this simple (I think). > > > >(The inset API has its nice sides) > > Thanks for helping me at this. > > Abdel. OK. Could you commit it? - Martin pgpVeQfsUwWXL.pgp Description: PGP signature
Re: [Patch] fix caption inset selection bug
Martin Vermeer wrote: It is this simple (I think). (The inset API has its nice sides) Thanks for helping me at this. Abdel.
[Patch] fix caption inset selection bug
It is this simple (I think).
(The inset API has its nice sides)
- Martin
Index: insetcaption.C
===
--- insetcaption.C (revision 17041)
+++ insetcaption.C (working copy)
@@ -167,6 +167,12 @@
}
+void InsetCaption::drawSelection(PainterInfo & pi, int x, int y) const
+{
+ InsetText::drawSelection(pi, x + labelwidth_ , y);
+}
+
+
void InsetCaption::edit(LCursor & cur, bool left)
{
cur.push(*this);
Index: insetcaption.h
===
--- insetcaption.h (revision 17041)
+++ insetcaption.h (working copy)
@@ -48,6 +48,8 @@
///
virtual void draw(PainterInfo & pi, int x, int y) const;
///
+ void drawSelection(PainterInfo & pi, int x, int y) const;
+ ///
virtual void edit(LCursor & cur, bool left);
///
virtual InsetBase * editXY(LCursor & cur, int x, int y);
pgpAlniywt4KX.pgp
Description: PGP signature
About the X11 selection bug
Hello, I've just committed a potential fix, can someone try again please? Abdel.
Re: another paste into selection bug
On Sun, Mar 16, 2003 at 12:58:15AM +1030, Darren Freeman wrote: > Select text, ctrl-C. > > Select other text, ctrl-P. > > The selection isn't replaced by the paste, it's just appended. Indeedy. Can you please file a bug on http://bugzilla.lyx.org/ thanks john
another paste into selection bug
Dear List, lyx1.3.1CVS, xforms-0.89 Select text, ctrl-C. Select other text, ctrl-P. The selection isn't replaced by the paste, it's just appended. Darren
Re: selection (?) bug
On Thu, Apr 18, 2002 at 10:08:41AM +0200, Juergen Spitzmueller wrote: > Now bug #331 > > How do I actually tell bugzilla to break the lines of my comment? dunno try doing it by hand :) john -- "Be advised. Your bedroom may quietly detach from the house while you sleep." - Sarah Bee
Re: selection (?) bug
Now bug #331 How do I actually tell bugzilla to break the lines of my comment? Juergen. Juergen Spitzmueller wrote: > Not on bugzilla I think. > > - Create a document with 3 standard paragraphs. > - Select the 3 paragraphs and change the environment (e.g. to enumerate) > > => only the first two paragraphs have been changed. > > Juergen.
selection (?) bug
Not on bugzilla I think. - Create a document with 3 standard paragraphs. - Select the 3 paragraphs and change the environment (e.g. to enumerate) => only the first two paragraphs have been changed. Juergen.
[PATCH] table selection - bug 451274
This patch catches all the things we need to prevent the table selection
goofing up.
please apply.
thanks
john
--
"We are all in the gutter, but some of us are looking at the pavement."
- Morrissey
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.236
diff -u -r1.236 ChangeLog
--- src/insets/ChangeLog2001/11/30 16:10:24 1.236
+++ src/insets/ChangeLog2001/12/01 14:01:17
@@ -1,3 +1,8 @@
+2001-12-01 John Levon <[EMAIL PROTECTED]>
+
+ * insettabular.C: capture some more functions to prevent
+ selection drawing problems. Bug #451274
+
2001-11-30 Juergen Vigna <[EMAIL PROTECTED]>
* insettabular.C (InsetTabular): use the save_id flag to create also
Index: src/insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.146
diff -u -r1.146 insettabular.C
--- src/insets/insettabular.C 2001/11/30 16:10:24 1.146
+++ src/insets/insettabular.C 2001/12/01 14:01:41
@@ -995,13 +995,25 @@
updateLocal(bv, CURSOR, false);
break;
}
+ // none of these make sense for insettabular,
+ // but we must catch them to prevent any
+ // selection from being confused
+ case LFUN_PRIORSEL:
+ case LFUN_NEXTSEL:
+ case LFUN_WORDLEFT:
+ case LFUN_WORDLEFTSEL:
+ case LFUN_WORDRIGHT:
+ case LFUN_WORDRIGHTSEL:
+ case LFUN_DOWN_PARAGRAPH:
+ case LFUN_DOWN_PARAGRAPHSEL:
+ case LFUN_UP_PARAGRAPH:
+ case LFUN_UP_PARAGRAPHSEL:
case LFUN_BACKSPACE:
- break;
case LFUN_DELETE:
- break;
case LFUN_HOME:
- break;
+ case LFUN_HOMESEL:
case LFUN_END:
+ case LFUN_ENDSEL:
break;
case LFUN_LAYOUT_TABULAR:
{
