Re: Behavior of overset inset creation on selection
Le 05/11/2018 à 05:43, Scott Kostyshak a écrit :
Please try the attached and tell me if you like it.
For me it doesn't make much of a difference for the use case I
mentioned. I now get the attached screenshot with those steps. Either
with this patch or without this patch, I need to click (or move with
cursor) on the box above "=" to enter "def" to get my desired output.
I indeed forget to test the initial use case. It was not working as
intended.
Try this pair of patch instead. The first one changes several classes so
that cell 0 is he 'main' cell. This makes many things simpler IMO.
The second patch is the one which does the requested change.
JMarc
>From 61addb872c6945af4206d8bbfbd1ff6d5339fb11 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Mon, 5 Nov 2018 21:29:47 -1000
Subject: [PATCH 1/2] Change cell numbers so that 0 is the main cell
This leads to code simplification in overset, root and underset.
Further simplification is possible.
---
src/mathed/InsetMathOverset.cpp | 43 +---
src/mathed/InsetMathOverset.h| 4 +--
src/mathed/InsetMathRoot.cpp | 23 +
src/mathed/InsetMathRoot.h | 5 +---
src/mathed/InsetMathUnderset.cpp | 41 +++---
src/mathed/InsetMathUnderset.h | 6 -
6 files changed, 57 insertions(+), 65 deletions(-)
diff --git a/src/mathed/InsetMathOverset.cpp b/src/mathed/InsetMathOverset.cpp
index 1295685d78..b659a9eab4 100644
--- a/src/mathed/InsetMathOverset.cpp
+++ b/src/mathed/InsetMathOverset.cpp
@@ -19,6 +19,8 @@
#include "LaTeXFeatures.h"
#include "MetricsInfo.h"
+#include "support/lassert.h"
+
using namespace std;
namespace lyx {
@@ -32,14 +34,14 @@ Inset * InsetMathOverset::clone() const
void InsetMathOverset::metrics(MetricsInfo & mi, Dimension & dim) const
{
Changer dummy2 = mi.base.changeEnsureMath();
- Dimension dim1;
- cell(1).metrics(mi, dim1);
- Changer dummy = mi.base.changeFrac();
Dimension dim0;
cell(0).metrics(mi, dim0);
- dim.wid = max(dim0.width(), dim1.wid) + 4;
- dim.asc = dim1.asc + dim0.height() + 4;
- dim.des = dim1.des;
+ Changer dummy = mi.base.changeFrac();
+ Dimension dim1;
+ cell(1).metrics(mi, dim1);
+ dim.wid = max(dim1.width(), dim0.wid) + 4;
+ dim.asc = dim0.asc + dim1.height() + 4;
+ dim.des = dim0.des;
}
@@ -47,13 +49,24 @@ void InsetMathOverset::draw(PainterInfo & pi, int x, int y) const
{
Changer dummy2 = pi.base.changeEnsureMath();
Dimension const dim = dimension(*pi.base.bv);
- Dimension const & dim0 = cell(0).dimension(*pi.base.bv);
Dimension const & dim1 = cell(1).dimension(*pi.base.bv);
+ Dimension const & dim0 = cell(0).dimension(*pi.base.bv);
int m = x + dim.wid / 2;
- int yo = y - dim1.asc - dim0.des - 1;
- cell(1).draw(pi, m - dim1.wid / 2, y);
+ int yo = y - dim0.asc - dim1.des - 1;
+ cell(0).draw(pi, m - dim0.wid / 2, y);
Changer dummy = pi.base.changeFrac();
- cell(0).draw(pi, m - dim0.width() / 2, yo);
+ cell(1).draw(pi, m - dim1.width() / 2, yo);
+}
+
+
+bool InsetMathOverset::idxUpDown(Cursor & cur, bool up) const
+{
+ idx_type target = up; // up ? 1 : 0, since upper cell has idx 1
+ if (cur.idx() == target)
+ return false;
+ cur.idx() = target;
+ cur.pos() = cur.cell().x2pos((), cur.x_target());
+ return true;
}
@@ -62,27 +75,27 @@ void InsetMathOverset::write(WriteStream & os) const
MathEnsurer ensurer(os);
if (os.fragile())
os << "\\protect";
- os << "\\overset{" << cell(0) << "}{" << cell(1) << '}';
+ os << "\\overset{" << cell(1) << "}{" << cell(0) << '}';
}
void InsetMathOverset::normalize(NormalStream & os) const
{
- os << "[overset " << cell(0) << ' ' << cell(1) << ']';
+ os << "[overset " << cell(1) << ' ' << cell(0) << ']';
}
void InsetMathOverset::mathmlize(MathStream & ms) const
{
- ms << "" << cell(1) << cell(0) << "";
+ ms << "" << cell(0) << cell(1) << "";
}
void InsetMathOverset::htmlize(HtmlStream & os) const
{
os << MTag("span", "class='overset'")
- << MTag("span", "class='top'") << cell(0) << ETag("span")
- << MTag("span") << cell(1) << ETag("span")
+ << MTag("span", "class='top'") << cell(1) << ETag("span")
+ << MTag("span") << cell(0) << ETag("span")
<< ETag("span");
}
diff --git a/src/mathed/InsetMathOverset.h b/src/mathed/InsetMathOverset.h
index 1202bbcfd4..eb6b86b798 100644
--- a/src/mathed/InsetMathOverset.h
+++ b/src/mathed/InsetMathOverset.h
@@ -28,9 +28,7 @@ public:
///
void draw(PainterInfo & pi, int x, int y) const;
///
- idx_type firstIdx() const { return 1; }
- ///
- idx_type lastIdx() const { return 1; }
+ bool idxUpDown(Cursor & cur, bool up) const;
///
void write(WriteStream & os) const;
///
diff --git a/src/mathed/InsetMathRoot.cpp b/src/mathed/InsetMathRoot.cpp
index 3cc8e2e1d7..b3723faca8 100644
--- a/src/mathed/InsetMathRoot.cpp
+++ b/src/mathed/InsetMathRoot.cpp
@@ -22,6 +22,7 @@
#include "frontends/Painter.h"
+#include "support/lassert.h"
using namespace std;
@@ -84,7 +85,7 @@
Re: LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics
I realized I was using the Lyx from the Ubuntu repository. When I removed it, added the PPA, and installed LyX from that -- it now seems to work. I do, however, have an odd problem where graphics often don't display in LyX, giving errors such as "error loading file into memory" or "error converting to loadable format" which I didn't get before upgrading to Ubuntu 18.04. Best regards, Jeff On Sat, Nov 3, 2018 at 1:23 PM Liviu Andronic wrote: > On 11/2/18, Richard Kimberly Heck wrote: > > Unfortunately, without debug symbols, the backtrace is unreadable. I > > don't know if there is an Ubuntu package that would allow you to install > > them. > > If the OP is using the LyX PPA, try to install the lyx-dbg package, > which should give the debugging symbols for LyX. > > Liviu > > > > But you could also try compiling from source with --enable-debug. > > > > Riki > > > > > > On 11/1/18 9:20 PM, Jeff Defoe wrote: > >> ( 1) lyx: lyx() [0x8de95d] > >> ( 2) lyx: lyx() [0x8b] > >> ( 3) lyx: lyx() [0x5a13dc] > >> ( 4) /lib/x86_64-linux-gnu/libc.so.6: > >> /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20] > >> ( 5) lyx: lyx() [0x902e5d] > >> ( 6) lyx: lyx() [0x90164c] > >> ( 7) lyx: lyx() [0x90b451] > >> ( 8) lyx: lyx() [0x6e9d1b] > >> ( 9) lyx: lyx() [0x6eba5b] > >> ( 10) lyx: lyx() [0x661239] > >> ( 11) lyx: lyx() [0x661932] > >> ( 12) lyx: lyx() [0x8b7b22] > >> ( 13) lyx: lyx() [0x7e899f] > >> ( 14) lyx: lyx() [0x6eb595] > >> ( 15) lyx: lyx() [0x6eba16] > >> ( 16) lyx: lyx() [0x661239] > >> ( 17) lyx: lyx() [0x661932] > >> ( 18) lyx: lyx() [0x6adf43] > >> ( 19) lyx: lyx() [0x93e374] > >> ( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > >> ( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*) > >> ( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, > QEvent*) > >> ( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplicationPrivate::notify_helper(QObject*, QEvent*) > >> ( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplication::notify(QObject*, QEvent*) > >> ( 25) lyx: lyx() [0x8f134c] > >> ( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplication::notifyInternal(QObject*, QEvent*) > >> ( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint > >> const&, int, QPainter*, QWidgetBackingStore*) > >> ( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8] > >> ( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QWidgetPrivate::syncBackingStore() > >> ( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*) > >> ( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QMainWindow::event(QEvent*) > >> ( 32) lyx: lyx() [0x92d70d] > >> ( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplicationPrivate::notify_helper(QObject*, QEvent*) > >> ( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> QApplication::notify(QObject*, QEvent*) > >> ( 35) lyx: lyx() [0x8f134c] > >> ( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplication::notifyInternal(QObject*, QEvent*) > >> ( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) > >> ( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e] > >> ( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7) > >> [0x7f83f85ee287] > >> ( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0] > >> ( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0: > >> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) > >> [0x7f83f85ee54c] > >> ( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> > QEventDispatcherGlib::processEvents(QFlags) > >> ( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: > >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666] > >> ( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QEventLoop::processEvents(QFlags) > >> ( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: > >> QEventLoop::exec(QFlags) > >> ( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec() > >> ( 47) lyx: lyx() [0x5aa17d] > >> ( 48) lyx: lyx() [0x43d5ad] > >> ( 49) /lib/x86_64-linux-gnu/libc.so.6: > >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97] > >> ( 50) lyx: lyx() [0x449539] > >> > > > > >
Re: Alignment of section titles in KOMA classes for RTL
Le 5 novembre 2018 06:29:48 GMT-10:00, Richard Kimberly Heck a écrit : >This sounds like a bug, but probably one it is fairly easy to fix. >JMarc >will probably know where this is to be done. Unfortunately, I do not >know where alignment is handled. Probably in the row metrics but I >can't >find it. > The code is in TextMetrics.cpp. There is some helper function there. I do not know though whether left is swapped to right or whether it should. JMarc
Re: Debugging question
Am Montag, 5. November 2018 11:20:33 CET schrieb Richard Kimberly Heck
:
> On 11/4/18 5:35 AM, Kornel Benko wrote:
> > I am hunting an error, which only shows if I disable the debug output.
> > So, using '-dbg find', there is no error, the findadv routines work OK.
> >
> > Without this, the outcome is surprising.
> > For instance open a file with some text in English and some in another
> > languages.
> >
> > In findadv deselect 'igmore format'
> > use regex '.+' and set the lang of regex to English
> >
> > Now, sometimes, not the whole English part is found.
> > The following search will find the remaining (or again only a part of the
> > remaining) and so on.
> >
> > The question is: What the hell is going on here? The code is the same,
> > only the debug output changes the behaviour.
> > Also debugging is difficult, because the wrong behaviour does not
> > appear consistently.
>
> That makes it sound like some kind of race condition. Are we doing
> background processing here somewhere?
According to outputs of the debugger, yes. Plenty. But I thought,
the reason was QT.
> Riki
For me it looks like some variables are not initialized correctly in calls to
TeXOnePar().
Indication to this is the following behavior:
1.) Start searching for bold strings (no ignore format)
\textbf{\regexp{.+\endregexp{}}
2.) After a while (many string found and correct) there is a too short match,
then the next and so on.
Later, starting anew on the position where the wrong matches previously
started, all matches are OK at first,
and the wrong matches are coming at another position.
But NEVER seen under gdb or if the debug 'find' is in effect.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: [LyX/master] Findadv: 'Optimized' detection of matched string
Am Montag, 5. November 2018 11:33:41 CET schrieb Richard Kimberly Heck : > On 11/4/18 8:57 AM, Kornel Benko wrote: > > commit aa68dcefa0aa4818b2d01d69e33db4906017ebfc > > Author: Kornel Benko > > Date: Sun Nov 4 14:54:06 2018 +0100 > > > > Findadv: 'Optimized' detection of matched string > > > > This is clearly a hack, because I don't understand why the > > previous code did not work. > > Is there any issue about .+ and the like matching newlines? I searched, but could not find any. Therefore I tried and it worked. (I needed a valid character for which '.' is not matching. In perl this is '\n', so it was also my first candidate) > For these purposes, outputting with really long lines probalby doesn't > matter, though, and it may make the code simpler. It matters also for short lines. (But I probably didn't get your point) > Riki Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Findadv: 'Optimized' detection of matched string
On 11/4/18 8:57 AM, Kornel Benko wrote: > commit aa68dcefa0aa4818b2d01d69e33db4906017ebfc > Author: Kornel Benko > Date: Sun Nov 4 14:54:06 2018 +0100 > > Findadv: 'Optimized' detection of matched string > > This is clearly a hack, because I don't understand why the > previous code did not work. Is there any issue about .+ and the like matching newlines? For these purposes, outputting with really long lines probalby doesn't matter, though, and it may make the code simpler. Riki
Re: Alignment of section titles in KOMA classes for RTL
On 11/4/18 2:49 PM, Guy Rutenberg wrote: > Hi, > > In the regular document classes, if a document's main language is > Hebrew, than alignment in LyX's display of section titles is > context-dependent (right if Hebrew, left otherwise). In the Koma > classes (for example KOMA-Script article) it does not work that way. > > I suspect the relevant code is the style in the layout file: > > Style Section > Align Left > Font > Family Sans > EndFont > End > > > Is there a way to instruct LyX to treat the Left Alignment as > direction-dependent automatically? Alternatively, can we change the > alignment to be "Block" as in the standard classes? This sounds like a bug, but probably one it is fairly easy to fix. JMarc will probably know where this is to be done. Unfortunately, I do not know where alignment is handled. Probably in the row metrics but I can't find it. Riki
Re: Debugging question
On 11/4/18 5:35 AM, Kornel Benko wrote: > I am hunting an error, which only shows if I disable the debug output. > So, using '-dbg find', there is no error, the findadv routines work OK. > > Without this, the outcome is surprising. > For instance open a file with some text in English and some in another > languages. > > In findadv deselect 'igmore format' > use regex '.+' and set the lang of regex to English > > Now, sometimes, not the whole English part is found. > The following search will find the remaining (or again only a part of the > remaining) and so on. > > The question is: What the hell is going on here? The code is the same, > only the debug output changes the behaviour. > Also debugging is difficult, because the wrong behaviour does not > appear consistently. That makes it sound like some kind of race condition. Are we doing background processing here somewhere? Riki
Re: Behavior of overset inset creation on selection
On Sun, Nov 04, 2018 at 09:32:49PM -1000, Jean-Marc Lasgouttes wrote: > Le 04/11/2018 à 11:16, Scott Kostyshak a écrit : > > I see, sounds tricky. Perhaps we should leave things untouched? Would it > > be complicated to allow for the multi-cell inset to decide what the > > behavior is? I'm guessing this would be too complicated and is not the > > best use of your time, but in case I'm wrong, if you implement the > > general framework, I could take care of auditing all of the individual > > insets and also poll lyx-users to see what is the most natural to all. > > Please try the attached and tell me if you like it. For me it doesn't make much of a difference for the use case I mentioned. I now get the attached screenshot with those steps. Either with this patch or without this patch, I need to click (or move with cursor) on the box above "=" to enter "def" to get my desired output. > I think personally that it makes sense. I trust whatever you think is best. I know nothing about the inner workings of this. Thanks for your work on it. Scott signature.asc Description: PGP signature
Re: Policy for breaking compilation with -Werror
Am Sonntag, 4. November 2018 14:50:00 CET schrieb Jean-Marc Lasgouttes
:
> Le 28/10/2018 à 09:39, Scott Kostyshak a écrit :
> > Dear all,
> >
> > I think that preserving compilation with -Werror can help catch real
> > bugs. Most of the time, warnings are harmless/incorrect, and can even be
> > a pain to address. It's thus debatable whether the bother of fixing
> > harmless/incorrect warnings is worth the small chance of catching a real
> > bug.
>
> Having a 0 warning build is of course a valuable goal, and we have done
> that for years. There are however warnings that we cannot really
> prevent, like the ones in code we do not control (I get some from
> qt-generated code, for example).
>
> > I would like to add a policy to our Development.lyx manual. The policies
> > we have in there are not hard policies and exceptions can always be
> > made. It would just be nice to have a basis for discussion.
>
> I am not against policies, unless we have to make unreasonable changes
> to code to meet them.
>
> > There is a recent issue that Kornel and I have been dealing with, where
> > the -Werror in GCC 7.3.0 is more strict than in GCC 5.4.0. I think this
> > is common, as compilers try to add detection of more potential problems.
> > However, it creates an extra burden on the developer because they need
> > to address a warning that does not show up for their GCC version.
>
> In this particular case, I do not think a convenience function for
> Kornel's debugging needs deserves code like
>
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wpragmas"
> #pragma GCC diagnostic ignored "-Wunused"
> #pragma GCC diagnostic ignored "-Wunused-function"
>
> #ifdef __GNUC__
> #define SUPPRESS_NOT_USED_WARN __attribute__ ((unused))
> #else
> #define SUPPRESS_NOT_USED_WARN
> #endif
>
> void SUPPRESS_NOT_USED_WARN setIgnoreFormat(string type, bool value)
> {
>IgnoreFormats().setIgnoreFormat(type, value);
> }
> #pragma GCC diagnostic pop
>
> Kornel, what if setIgnoreFormat() was renamed to set()? Then calling
> IgnoreFormats::set() is not really worse than your setIgnoreFormat() helper?
It is not meant as a convenient debugging function. I was hoping to use this
function
from a dialog where one would set ignoring options.
> I know I am getting away from the big principles, but I think that
> avoiding warnings can often be done by pragmatic solutions.
>
> Another possibility:
> #define setIgnoreFormat(type, bool) IgnoreFormats::setIgnoreFormat(type,
> value)
>
> BTW I have questions on this code:
> - IgnoreFormat is not a class, since it does not hold data. Basically,
> this is a namespace with global data in it. In this respect, I do not
> understand what IgnoreFormat() means.
See below
> - This means that the "IgnoreFormats f" member hold by the LaTeXInfo
> class does not make sense.
>
> What I would propose is to remove the "static" specifiers in the class
> definition. Then one would need to instantiate a IgnoreFormats instance
> everytime we need one.
Please no. We need exactly the same data for all subsequent matches. I prefer
to not recreate them each time. And if we recreate it, we need another set of
static vars
for initialization ... this makes no sense for me.
> JMarc
Kornel
signature.asc
Description: This is a digitally signed message part.
