On Fri, Oct 14, 2022 at 9:38 AM Jürgen Spitzmüller
wrote:
> Am Freitag, dem 14.10.2022 um 08:51 -0600 schrieb Joel Kulesza:
> > Another area where I hope we can consider background coloring of
> > these types of items is based on whether links get resolved. That
> > is, a broken cross reference
Am Freitag, dem 14.10.2022 um 08:51 -0600 schrieb Joel Kulesza:
> Another area where I hope we can consider background coloring of
> these types of items is based on whether links get resolved. That
> is, a broken cross reference or "citation not found" being colored
> differently will help
On Sun, Oct 9, 2022 at 1:02 PM Paul A. Rubin wrote:
> On 10/9/22 12:30, Jean-Marc Lasgouttes wrote:
> > Le 09/10/2022 à 17:28, Rodolfo Oviedo a écrit :
> >> Hi Jean-Marc,
> >>
> >> Thank you for your reply!
> >
> > You are welcome. Please keep lyx-devel in copy, it is better to share
> > our
On 10/9/22 12:30, Jean-Marc Lasgouttes wrote:
Le 09/10/2022 à 17:28, Rodolfo Oviedo a écrit :
Hi Jean-Marc,
Thank you for your reply!
You are welcome. Please keep lyx-devel in copy, it is better to share
our thoughts with everyone.
I agree that it is enough. However, I think it is not
to suggestions!
Rodolfo
-Original Message-
From: Jean-Marc Lasgouttes
Sent: Sunday, October 9, 2022 13:31
To: Rodolfo Oviedo ; LyX Developers
Subject: Re: Different color of cursor in Math and Text Modes
Le 09/10/2022 à 17:28, Rodolfo Oviedo a écrit :
> Hi Jean-Marc,
>
>
Le 09/10/2022 à 17:28, Rodolfo Oviedo a écrit :
Hi Jean-Marc,
Thank you for your reply!
You are welcome. Please keep lyx-devel in copy, it is better to share
our thoughts with everyone.
I agree that it is enough. However, I think it is not optimum, especially
because the corners are too
enough to signal
that it is currently edited?
JMarc
Alternatives:
1. Include tow different color preferences: one for cursor in text and
another for cursor in math.
2. Make the cursor automatically take the color of text or math
according to the environment. If you prefer 1, I
Hi,
It would be easier to spot if the cursor is at the beginning of the end of a
math area or just besides if the color of the cursor were different in math and
text mode.
Alternatives:
1. Include tow different color preferences: one for cursor in text and
another for cursor in math.
2
Hi Antonio,
Antonio Rieser wrote:
Two problems. I'm using LyX on the Mac (OS X.3/4.?)
Which Mac OS X and which LyX version?
for the
first time, and after I choose 'Section' and then type, the text on
the line I'm typing jumps to the right, but the cursor stays where it
is. It drives me
Hi,
Lyx 1.5.6, Mac OS X.3.9. I do have 'right to left language support'
activated, but deactivating it doesn't change anything.
Thanks, and all the best,
Tony
On Wed, Oct 22, 2008 at 2:38 AM, Konrad Hofbauer [EMAIL PROTECTED]wrote:
Hi Antonio,
Antonio Rieser wrote:
Two problems.
Hi Antonio,
Antonio Rieser wrote:
> Two problems. I'm using LyX on the Mac (OS X.3/4.?)
Which Mac OS X and which LyX version?
> for the
> first time, and after I choose 'Section' and then type, the text on
> the line I'm typing jumps to the right, but the cursor stays where it
> is. It
Hi,
Lyx 1.5.6, Mac OS X.3.9. I do have 'right to left language support'
activated, but deactivating it doesn't change anything.
Thanks, and all the best,
Tony
On Wed, Oct 22, 2008 at 2:38 AM, Konrad Hofbauer <[EMAIL PROTECTED]>wrote:
>
>
> Hi Antonio,
>
> Antonio Rieser wrote:
> > Two
Abdelrazak Younes wrote:
Andre Poenitz wrote:
During selection one can't leave a nested inset anymore.
Confirmed.
Hum... probably my fault, I'll have a look.
Doesn't seem to be my fault after all, I only changed the text mouse
selection part...
Abdel.
Abdelrazak Younes wrote:
Andre Poenitz wrote:
During selection one can't leave a nested inset anymore.
Confirmed.
Hum... probably my fault, I'll have a look.
Doesn't seem to be my fault after all, I only changed the text mouse
selection part...
Abdel.
Andre Poenitz wrote:
During selection one can't leave a nested inset anymore.
Hum... probably my fault, I'll have a look.
Abdel.
Andre Poenitz wrote:
During selection one can't leave a nested inset anymore.
Hum... probably my fault, I'll have a look.
Abdel.
During selection one can't leave a nested inset anymore.
Andre'
During selection one can't leave a nested inset anymore.
Andre'
If we want this, another OK is needed.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
JMarc
Am 14.06.2007 um 10:39 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
Sure, inlined and attached:
Index: lyx-devel/src/Cursor.cpp
Stefan Schimanski wrote:
Am 14.06.2007 um 10:39 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski
[EMAIL PROTECTED] writes:
Stefan If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
Sure, inlined and attached:
Works for me (when
Works for me (when leaving the macro using down key, macro
collapses). I don't have the first part of the patch in, though, so
down doesn't move to the second parameter, but directly out --- but
that's to be expected, right?
Thanks for testing! You are right. I have split the two (in fact
Stefan Schimanski wrote:
Works for me (when leaving the macro using down key, macro collapses).
I don't have the first part of the patch in, though, so down doesn't
move to the second parameter, but directly out --- but that's to be
expected, right?
Thanks for testing! You are right. I have
Am 14.06.2007 um 22:45 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Works for me (when leaving the macro using down key, macro
collapses). I don't have the first part of the patch in, though,
so down doesn't move to the second parameter, but directly out
--- but that's to be
If we want this, another OK is needed.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
JMarc
Am 14.06.2007 um 10:39 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
Sure, inlined and attached:
Index: lyx-devel/src/Cursor.cpp
Stefan Schimanski wrote:
Am 14.06.2007 um 10:39 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski
<[EMAIL PROTECTED]> writes:
Stefan> If we want this, another OK is needed. Stefan
I missed the latest patch. COuld you report it please?
Sure, inlined and attached:
Works for me
Works for me (when leaving the macro using down key, macro
collapses). I don't have the first part of the patch in, though, so
down doesn't move to the second parameter, but directly out --- but
that's to be expected, right?
Thanks for testing! You are right. I have split the two (in fact
Stefan Schimanski wrote:
Works for me (when leaving the macro using down key, macro collapses).
I don't have the first part of the patch in, though, so down doesn't
move to the second parameter, but directly out --- but that's to be
expected, right?
Thanks for testing! You are right. I have
Am 14.06.2007 um 22:45 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Works for me (when leaving the macro using down key, macro
collapses). I don't have the first part of the patch in, though,
so down doesn't move to the second parameter, but directly out
--- but that's to be
Stefan Schimanski wrote:
Right, too late for 1.5. Still the inverse logic is better IMHO.
So it marks the lfun as undispatched. But then the Update::Force
flag is overwritten later by the cursor down handler of the text.
Maybe you could change this overwritting?
As far
as I see there is no
I mean: if (cur.result().update() == Update::Force) this means
that the flag has been explicitely set previously as opposed to
have the default value (Update::FitCursor | Update::Force). Maybe
this information could be used?
Here is a solution in the direction I described: the old cursor is
Stefan Schimanski wrote:
I mean: if (cur.result().update() == Update::Force) this means that
the flag has been explicitely set previously as opposed to have the
default value (Update::FitCursor | Update::Force). Maybe this
information could be used?
Here is a solution in the direction I
Stefan Schimanski wrote:
Right, too late for 1.5. Still the inverse logic is better IMHO.
So it marks the lfun as undispatched. But then the Update::Force
flag is overwritten later by the cursor down handler of the text.
Maybe you could change this overwritting?
As far
as I see there is no
I mean: if (cur.result().update() == Update::Force) this means
that the flag has been explicitely set previously as opposed to
have the default value (Update::FitCursor | Update::Force). Maybe
this information could be used?
Here is a solution in the direction I described: the old cursor is
Stefan Schimanski wrote:
I mean: if (cur.result().update() == Update::Force) this means that
the flag has been explicitely set previously as opposed to have the
default value (Update::FitCursor | Update::Force). Maybe this
information could be used?
Here is a solution in the direction I
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The MathMacro get's the
notifyCursorLeaves call. It then sets the Update::Force flag to
Am 12.06.2007 um 10:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is
not called. Had noticed that before some time ago. Will look into
it.
This whole updateflag business makes me crazy. The MathMacro get's
the
Stefan Schimanski wrote:
Am 12.06.2007 um 10:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The
As far
as I see there is no way to trigger a complete redraw reliable
from anywhere else than the inset which dispatches the lfun.
If the Cursor is passed there is: by checking and accumulating
the update flag.
What do you mean? I don't see how to do anything like that.
I mean: if
The real problem is the notifyCursorLeaves is called in a chaotic
way. In certain functions like Cursor::popLeft, or the handler for
mouse click in the BufferView, this function is called. But of course
there can be plenty of way to leave an inset. A clean way would be to
remove these
Ah yes I remember... I wanted to inverse the logic but never found
the time to do so.
So checking for Update::Force is not possible like that. And
setting it to NoUpdate first and then check for Force will break a
lot I guess.
Right, too late for 1.5. Still the inverse logic is better
Right, too late for 1.5. Still the inverse logic is better IMHO.
So it marks the lfun as undispatched. But then the Update::Force
flag is overwritten later by the cursor down handler of the text.
Maybe you could change this overwritting?
As far
as I see there is no way to trigger a
And with this change you can leave mathed with cursor up/down and get
the math redrawn for the decorations:
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 18737)
+++ src/Text3.cpp (Arbeitskopie)
@@ -512,24
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The MathMacro get's the
notifyCursorLeaves call. It then sets the Update::Force flag to
Am 12.06.2007 um 10:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is
not called. Had noticed that before some time ago. Will look into
it.
This whole updateflag business makes me crazy. The MathMacro get's
the
Stefan Schimanski wrote:
Am 12.06.2007 um 10:22 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The
As far
as I see there is no way to trigger a complete redraw reliable
from anywhere else than the inset which dispatches the lfun.
If the Cursor is passed there is: by checking and accumulating
the update flag.
What do you mean? I don't see how to do anything like that.
I mean: if
The real problem is the notifyCursorLeaves is called in a chaotic
way. In certain functions like Cursor::popLeft, or the handler for
mouse click in the BufferView, this function is called. But of course
there can be plenty of way to leave an inset. A clean way would be to
remove these
Ah yes I remember... I wanted to inverse the logic but never found
the time to do so.
So checking for Update::Force is not possible like that. And
setting it to NoUpdate first and then check for Force will break a
lot I guess.
Right, too late for 1.5. Still the inverse logic is better
Right, too late for 1.5. Still the inverse logic is better IMHO.
So it marks the lfun as undispatched. But then the Update::Force
flag is overwritten later by the cursor down handler of the text.
Maybe you could change this overwritting?
As far
as I see there is no way to trigger a
And with this change you can leave mathed with cursor up/down and get
the math redrawn for the decorations:
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 18737)
+++ src/Text3.cpp (Arbeitskopie)
@@ -512,24
Stefan Schimanski wrote:
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
I won't dispute the obviousness of it with our macro expert ;-)
Abdel.
Need another OK. Anybody? José?
Stefan
Am 09.06.2007 um 18:29 schrieb Stefan Schimanski:
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
---
Stefan Schimanski wrote:
Need another OK. Anybody? José?
Hi!
1. I have trouble applying the patches that you inline in the emails ---
it's something with the whitespace, I think, but I always get malformed
patch messages, and end up having to type them in by hand...
2. I got this error:
Thanks for testing!
1. I have trouble applying the patches that you inline in the
emails --- it's something with the whitespace, I think, but I
always get malformed patch messages, and end up having to type
them in by hand...
Yes, in fact same for me with other people's inlined patches.
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The MathMacro get's
the notifyCursorLeaves call. It then sets the Update::Force flag to
trigger a redraw. But
On Mon, Jun 11, 2007 at 08:32:44PM +0200, Stefan Schimanski wrote:
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++
And this MathMacro:: qualification is useless at best, but I have a
strong suspicion that it is not allowed at all.
Was a copy/paste mistake and an Xcode not saving the file before my
svn diff...
PS: I seem to remember to have something like that as 'generic'
implementation in
Stefan Schimanski wrote:
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
I won't dispute the obviousness of it with our macro expert ;-)
Abdel.
Need another OK. Anybody? José?
Stefan
Am 09.06.2007 um 18:29 schrieb Stefan Schimanski:
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
---
Stefan Schimanski wrote:
Need another OK. Anybody? José?
Hi!
1. I have trouble applying the patches that you inline in the emails ---
it's something with the whitespace, I think, but I always get "malformed
patch" messages, and end up having to type them in by hand...
2. I got this
Thanks for testing!
1. I have trouble applying the patches that you inline in the
emails --- it's something with the whitespace, I think, but I
always get "malformed patch" messages, and end up having to type
them in by hand...
Yes, in fact same for me with other people's inlined
No, it's not intentional. It's a bug that notifyCursorLeaves is not
called. Had noticed that before some time ago. Will look into it.
This whole updateflag business makes me crazy. The MathMacro get's
the notifyCursorLeaves call. It then sets the Update::Force flag to
trigger a redraw. But
On Mon, Jun 11, 2007 at 08:32:44PM +0200, Stefan Schimanski wrote:
> >Index: lyx-devel/src/mathed/MathMacro.cpp
> >===
> >--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
> >11:24:05.0 +0200
> >+++
And this MathMacro:: qualification is useless at best, but I have a
strong suspicion that it is not allowed at all.
Was a copy/paste mistake and an Xcode not saving the file before my
svn diff...
PS: I seem to remember to have something like that as 'generic'
implementation in
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++
Looks like I forgot to send this answer...
Andre Poenitz wrote:
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
You misunderstood the problem.
Probably.
Drawing math is not faster nor slower than the rest. What's
problematic is to have to redraw when navigating with the
Looks like I forgot to send this answer...
Andre Poenitz wrote:
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
You misunderstood the problem.
Probably.
Drawing math is not faster nor slower than the rest. What's
problematic is to have to redraw when navigating with the
On Sun, Nov 26, 2006 at 12:09:47AM +0100, Enrico Forestieri wrote:
Please not. I think that if your formula doesn't fit on screen, even
after enlarging the window to full screen size, chances are that it
will not fit on paper, too.
That's not true if you use a lot of ERT in math.
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
You misunderstood the problem.
Probably.
Drawing math is not faster nor slower than the rest. What's
problematic is to have to redraw when navigating with the mouse or the
keyboard. We don't need to redraw for other insets,
On Sun, Nov 26, 2006 at 12:09:47AM +0100, Enrico Forestieri wrote:
> Please not. I think that if your formula doesn't fit on screen, even
> after enlarging the window to full screen size, chances are that it
> will not fit on paper, too.
That's not true if you use a lot of ERT in math.
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
> You misunderstood the problem.
Probably.
> Drawing math is not faster nor slower than the rest. What's
> problematic is to have to redraw when navigating with the mouse or the
> keyboard. We don't need to redraw for other
On Wed, Nov 22, 2006 at 01:38:25PM +0100, Edwin Leuven wrote:
(are there situations where the cursor position is not enough? if not
then we could get rid of these boxes altogether?)
Sure. There are cases where cursor positions vary only by a pixel or so
but it's structually differnt. The pink
On Wed, Nov 22, 2006 at 03:47:26PM +0100, Georg Baum wrote:
Abdelrazak Younes wrote:
I'll put them back. But it would be very nice to find some other
solution...
I don't think so. The box corners have the advantage that they consume very
little space and yet make it very clear where an
On Wed, Nov 22, 2006 at 03:59:42PM +0100, Abdelrazak Younes wrote:
OK, space is not a good idea. But what about different background colors?
Might work. But I guess you'll end up with situations where the cursor
is just on the border and if you have background colors independently
from the
On Wed, Nov 22, 2006 at 12:08:03PM +0100, Abdelrazak Younes wrote:
The problem is that displaying it would provoke a full redraw and
repaint. I think it is OK if we don't displayed it when clicking but
only when typing characters. This is a good compromise for performance
IMHO as you don't
Andre Poenitz wrote:
On Wed, Nov 22, 2006 at 03:59:42PM +0100, Abdelrazak Younes wrote:
OK, space is not a good idea. But what about different background colors?
Might work. But I guess you'll end up with situations where the cursor
is just on the border and if you have background colors
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
[...]
Another solution would be line breaks within a cell that are only stored
in the lyx file and get not exported (or turned into something harmless)
when exporting to .tex (the latter to give tex2lyx
Enrico Forestieri wrote:
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
[...]
Another solution would be line breaks within a cell that are only stored
in the lyx file and get not exported (or turned into something harmless)
when exporting to .tex (the
On Wed, Nov 22, 2006 at 01:38:25PM +0100, Edwin Leuven wrote:
> (are there situations where the cursor position is not enough? if not
> then we could get rid of these boxes altogether?)
Sure. There are cases where cursor positions vary only by a pixel or so
but it's structually differnt. The
On Wed, Nov 22, 2006 at 03:47:26PM +0100, Georg Baum wrote:
> Abdelrazak Younes wrote:
>
> > I'll put them back. But it would be very nice to find some other
> > solution...
>
> I don't think so. The box corners have the advantage that they consume very
> little space and yet make it very clear
On Wed, Nov 22, 2006 at 03:59:42PM +0100, Abdelrazak Younes wrote:
> OK, space is not a good idea. But what about different background colors?
Might work. But I guess you'll end up with situations where the cursor
is just on the border and if you have background colors independently
from the
On Wed, Nov 22, 2006 at 12:08:03PM +0100, Abdelrazak Younes wrote:
> The problem is that displaying it would provoke a full redraw and
> repaint. I think it is OK if we don't displayed it when clicking but
> only when typing characters. This is a good compromise for performance
> IMHO as you
Andre Poenitz wrote:
On Wed, Nov 22, 2006 at 03:59:42PM +0100, Abdelrazak Younes wrote:
OK, space is not a good idea. But what about different background colors?
Might work. But I guess you'll end up with situations where the cursor
is just on the border and if you have background colors
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
[...]
> > Another solution would be line breaks within a cell that are only stored
> > in the lyx file and get not exported (or turned into something harmless)
> > when exporting to .tex (the latter to give
Enrico Forestieri wrote:
On Sat, Nov 25, 2006 at 11:37:29AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
[...]
Another solution would be line breaks within a cell that are only stored
in the lyx file and get not exported (or turned into something harmless)
when exporting to .tex (the
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Abdelrazak Younes wrote:
I'll put them back. But it would be very nice to find some other
solution...
Georg I don't think so. The box corners have the advantage that they
Georg consume very little space and yet make it very clear where an
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Abdelrazak Younes wrote:
>> I'll put them back. But it would be very nice to find some other
>> solution...
Georg> I don't think so. The box corners have the advantage that they
Georg> consume very little space and yet make it very
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
always moves first to the beginning of the inset before showning up
at the right place on mouse click
(hope this is clear)
The attached patch fixes this and avoid many redrawing following mouse
or keyboard navigation (using
Abdelrazak Younes wrote:
sometimes the cursor flashes at the beginning of the inset,
double clicking always flashes the cursor at the beginning
LFUN_MOUSE_MOTION needs to be optimized also so that no redraw
happens if there is no selection (or no additional selection).
LFUN_DOUBLE_CLICK needs
Edwin Leuven wrote:
Abdelrazak Younes wrote:
The problem is that displaying it would provoke a full redraw and
repaint. I think it is OK if we don't displayed it when clicking but
only when typing characters. This is a good compromise for
performance IMHO as you don't really need the frame
Georg Baum wrote:
Yes, it is needed. Guess why the box was introduced? because it is
impossible to tell where exactly your are without it. It makes a big
difference if you enter the next character before or after the \mathbf in
\mathbf{\bigg xxx}}. You cannot distinguis these two positions
Georg Baum wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
The problem is that displaying it would provoke a full redraw and
repaint. I think it is OK if we don't displayed it when clicking but
only when typing characters. This is a good compromise for
performance IMHO as you don't
Edwin Leuven wrote:
Abdelrazak Younes wrote:
also the box around the math inset is not always displayed when
clicking there
The problem is that displaying it would provoke a full redraw and
repaint. I think it is OK if we don't displayed it when clicking but
only when typing characters.
Abdelrazak Younes wrote:
As it is now, no way. We have to redraw everything.
so be it. can we still get rid of the blinking cursor at the beginning
of the inset?
PS if i selecting something in a math inset and then move the cursor
right or left the selection is not cleared
Indeed, I will
Edwin Leuven wrote:
Abdelrazak Younes wrote:
As it is now, no way. We have to redraw everything.
so be it.
You mean that you prefer that the box corners stay?
can we still get rid of the blinking cursor at the beginning
of the inset?
Maybe, I am not sure.
Abdel.
1 - 100 of 200 matches
Mail list logo
