Re: Branches and InsetLayout
Sorry, should be fixed.
Riki
Thanks for the quick fix!
Seems your original patch also works good if we remove default
labelstring_ value (from_ascii("UNDEFINED")) in InsetLayout.h. And
Customization.lyx also says that default LabelString is "", not "UNDEFINED".
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Branches and InsetLayout
I can easily see someone using "_" in a branch name and then wondering why the InsetLayout doesn't work. Like I did. Pushed. Also fixed the label string issue. Riki Hi Riki, After this update the insets for normal branches (without custom InsetLayout) are shown with label "UNDEFINED". Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Update ru.po and UserGuide
If previous versions will be left, then there will be duplicated items in menu since these linguistics tables "tableaux" translate just as "tables". So I added these "(ling.)" prefixes to distinguish them. There is also a calque from "tableau" word, but it has different meaning and does not fit here. Well I doubt that you want to have "Table (lit.)" in the latex output, but if there is no corresponding word for tableaux in your language, then this whole discussion is probably void anyway. In next iteration I'll replace the strings in layouttranslation in whatever you decide is best and is present in the .po file. Pavel So, in several linguistics articles I've found another term used for tableau -- матрица/matrix instead of таблица/table. Let's hope linguists will be happy with this or will reply and come up with better translation :) Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Update ru.po and UserGuide
I would like to check with you the changes wrt lib/layouttranslations for PDF outputs. With the current .po version I see two changes (see attachment), which look wrong to me. Wouldn't be more correct to leave it in the previous version without braces? Pavel diff --git a/lib/layouttranslations b/lib/layouttranslations index 376e93ca77..3a31e9a82f 100644 --- a/lib/layouttranslations +++ b/lib/layouttranslations @@ -1306,7 +1306,7 @@ Translation ru "List of Graphs[[mathematical]]" "ХпиŃОк ĐłŃĐ°ŃикОв" "List of Listings" "ХпиŃОк НиŃŃингОв" "List of Schemes" "ХпиŃОк ŃŃ ĐľĐź" - "List of Tableaux" "ХпиŃОк ŃайНиŃ" + "List of Tableaux" "ХпиŃОк ŃĐ°ĐąĐťĐ¸Ń (Нингв.)" "Listing" "ĐиŃŃинг" "Listings[[List of Listings]]" "ĐиŃŃинги" "Nomenclature[[output]]" "ХпиŃОк ОйОСнаŃониК" @@ -1322,7 +1322,7 @@ Translation ru "Scheme" "ĐĄŃ ĐľĐźĐ°" "Solution" "Đ ĐľŃонио" "Summary" "РоСŃПо" - "Tableau" "ТайНиŃĐ°" + "Tableau" "ТайНиŃĐ° (Нингв.)" "Theorem" "ТоОŃоПа" "page[[nomencl]]" "ŃŃŃ." "see equation[[nomencl]]" "ŃĐź." Hi Pavel, If previous versions will be left, then there will be duplicated items in menu since these linguistics tables "tableaux" translate just as "tables". So I added these "(ling.)" prefixes to distinguish them. There is also a calque from "tableau" word, but it has different meaning and does not fit here. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Enable HTTPS access to LyX repo
Hello all, Currently LyX repo can be accessed only with SSH (read-write) and Git (read-only) protocols. Git protocol is obsolete and insecure. It is already disabled on GitHub: https://github.blog/2021-09-01-improving-git-protocol-security-github/ So, I propose to enable HTTPS for read-only access to the repo. Since https://git.lyx.org/ already runs Apache, I guess these instructions can be used for this: https://wiki.archlinux.org/title/Git_server#Smart_HTTP https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP Best Regards, Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: trac & gmail
On 16.06.2023 12:17, Pavel Sanda wrote: On Fri, Jun 16, 2023 at 06:01:48AM -0400, Scott Kostyshak wrote: On Fri, Jun 16, 2023 at 11:52:56AM +0200, Pavel Sanda wrote: On Fri, Jun 16, 2023 at 05:42:08AM -0400, Scott Kostyshak wrote: I'm still using GMail. I don't remember how I set things up though. I do receive notifications. Nope, you are using @lyx.org forward. P Ah, good to know :) Which would be temporary way to go for you Yuriy... Just CC with your @lyx account, not gmail one - I do not have better solution ATM, sorry. Thanks for the suggestion! I've just set @lyx email address in tracker settings since I also have forwarding from it to @gmail. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Can't login or reset password on trac
Dear devs, I can't seem to access the bug reporter. Using my usual login info gives me an "invalid password or username" error. Attempting to restore the passoword results in the mail not being sent. I was just able to log in. I'll privately send you a temporary password. Riki Hello, I also cannot login to the Bug Tracker and get the same error. Riki please send me the new password (login: magistere). Thanks, Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx error not as informative when opening newer file
And opening such file with non-existing version in LyX (master, Win10) gives that old message: is from a newer version of LyX and the lyx2lyx script failed to convert it. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx error not as informative when opening newer file
On 10.12.2022 15:22, Scott Kostyshak wrote: If you open a new .lyx file than the lyx2lyx version can handle we used to get: is from a newer version of LyX and the lyx2lyx script failed to convert it. Now we get: is not a readable LyX document. You can test this by just manually incremending the number in the first line of a .lyx file. Bisect leads to: commit fb7b7e5223bc0a03e5b4a89b15f1be0bc0d05385 Author: Yuriy Skalko Date: Fri Sep 11 00:22:55 2020 +0300 Refactor runCommand Yuriy, do you by chance have time to take a look? If not, no problem, I can take a look. Scott Hi Scott, I've not much experienced with lyx2lyx, can you describe exactly how to reproduce this? What OS do you use in your test? On manual incrementing the number I've got: lyx2lyx warning: 613: Format not supported. lyx2lyx warning: Quitting. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Semantic Linefeeds
.. and please add some note into https://wiki.lyx.org/LyX/NewInLyX24 .. Pavel Thanks for the reminder. Committed and documented. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Semantic Linefeeds
This looks good to me.
JMarc
Ok, here is an updated patch with dummy format change.
Yuriy
From 945e020306df7ea595e792284c3e427f32682fb0 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 27 Nov 2022 18:30:26 +0200
Subject: [PATCH] Add "semantic linefeeds" after punctuation marks.
We already had such breaks for dot.
File format change.
---
development/FORMAT | 4
lib/lyx2lyx/lyx_2_4.py | 6 --
src/Paragraph.cpp | 26 ++
src/version.h | 4 ++--
4 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/development/FORMAT b/development/FORMAT
index 0c41d8801c..5fcf13ebf1 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -7,6 +7,10 @@ changes happened in particular if possible. A good example
would be
---
+2022-11-27 Yuriy Skalko
+ * Format incremented to 611: Implement "semantic linefeeds" after
punctuation marks.
+ Dummy format change for now.
+
2022-10-29 Jürgen Spitzmüller
* Format incremented to 610: InsetIndexMacros and new IndexInset params:
- \begin_inset IndexMacro [see|seealso|subentry|sortkey], relating to
diff --git a/lib/lyx2lyx/lyx_2_4.py b/lib/lyx2lyx/lyx_2_4.py
index 73826a5f59..5c0507a5af 100644
--- a/lib/lyx2lyx/lyx_2_4.py
+++ b/lib/lyx2lyx/lyx_2_4.py
@@ -4621,10 +4621,12 @@ convert = [
[607, []],
[608, []],
[609, []],
- [610, []]
+ [610, []],
+ [611, []]
]
-revert = [[609, [revert_index_macros]],
+revert = [[610, []],
+ [609, [revert_index_macros]],
[608, [revert_document_metadata]],
[607, [revert_docbook_mathml_prefix]],
[606, [revert_spellchecker_ignore]],
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 3b3bc3913e..453b1e1bb5 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1746,16 +1746,34 @@ void Paragraph::write(ostream & os, BufferParams const
& bparams,
column = 0;
break;
case '.':
+ case '!':
+ case '?':
+ case ':':
+ case ';':
+ case ',':
+ case 0x061F: // ؟ U+061F ARABIC QUESTION MARK
+ case 0x061B: // ؛ U+061B ARABIC SEMICOLON
+ case 0x060C: // ، U+060C ARABIC COMMA
flushString(os, write_buffer);
if (i + 1 < size() && d->text_[i + 1] == ' ') {
- os << ".\n";
+ os << to_utf8(docstring(1, c)) << '\n';
column = 0;
} else
- os << '.';
+ os << to_utf8(docstring(1, c));
+ break;
+ case 0x2014: // — U+2014 EM DASH
+ case 0x3002: // 。 U+3002 IDEOGRAPHIC FULL STOP
+ case 0xFF01: // ！ U+FF01 FULLWIDTH EXCLAMATION MARK
+ case 0xFF1F: // ？ U+FF1F FULLWIDTH QUESTION MARK
+ case 0xFF1A: // ： U+FF1A FULLWIDTH COLON
+ case 0xFF1B: // ； U+FF1B FULLWIDTH SEMICOLON
+ case 0xFF0C: // ， U+FF0C FULLWIDTH COMMA
+ flushString(os, write_buffer);
+ os << to_utf8(docstring(1, c)) << '\n';
+ column = 0;
break;
default:
- if ((column > 70 && c == ' ')
- || column > 79) {
+ if (column > 500) {
flushString(os, write_buffer);
os << '\n';
column = 0;
diff --git a/src/version.h b/src/version.h
index b496d1045d..bfcd9869ae 100644
--- a/src/version.h
+++ b/src/version.h
@@ -32,8 +32,8 @@ extern char const * const lyx_version_info;
// Do not remove the comment below, so we get merge conflict in
// independent branches. Instead add your own.
-#define LYX_FORMAT_LYX 610 // spitz: inset index macros
-#define LYX_FORMAT_TEX2LYX 610
+#define LYX_FORMAT_LYX 611 // Yuriy Skalko: semantic linefeeds
+#define LYX_FORMAT_TEX2LYX 611
#if LYX_FORMAT_TEX2LYX != LYX_FORMAT_LYX
#ifndef _MSC_VER
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Semantic Linefeeds
I haven't tested, but how does this work when those punctuation symbols are not used to end clauses? For example, in the case of: "e.g., some text..." How many lines would this produce? Scott Just 2 lines. There should be a space to have a linebreak. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Semantic Linefeeds
Now the patch also contains most punctuation marks for non-European
languages after which it is worth to put a linebreak.
Is it ready to commit now?
Yuriy
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 4ce94415f7..7b3d5bd4f7 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1746,16 +1746,34 @@ void Paragraph::write(ostream & os, BufferParams const
& bparams,
column = 0;
break;
case '.':
+ case '!':
+ case '?':
+ case ':':
+ case ';':
+ case ',':
flushString(os, write_buffer);
if (i + 1 < size() && d->text_[i + 1] == ' ') {
- os << ".\n";
+ os << to_utf8(docstring(1, c)) << '\n';
column = 0;
} else
- os << '.';
+ os << to_utf8(docstring(1, c));
+ break;
+ case 0x2014: // — U+2014 EM DASH
+ case 0x3002: // 。 U+3002 IDEOGRAPHIC FULL STOP
+ case 0xFF01: // ！ U+FF01 FULLWIDTH EXCLAMATION MARK
+ case 0xFF1F: // ？ U+FF1F FULLWIDTH QUESTION MARK
+ case 0xFF1A: // ： U+FF1A FULLWIDTH COLON
+ case 0xFF1B: // ； U+FF1B FULLWIDTH SEMICOLON
+ case 0xFF0C: // ， U+FF0C FULLWIDTH COMMA
+ case 0x061F: // ؟ U+061F ARABIC QUESTION MARK
+ case 0x061B: // ؛ U+061B ARABIC SEMICOLON
+ case 0x060C: // ، U+060C ARABIC COMMA
+ flushString(os, write_buffer);
+ os << to_utf8(docstring(1, c)) << '\n';
+ column = 0;
break;
default:
- if ((column > 70 && c == ' ')
- || column > 79) {
+ if (column > 500) {
flushString(os, write_buffer);
os << '\n';
column = 0;
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Semantic Linefeeds
Here is an updated patch with Chinese punctuation marks. Also now
linebreak is added after em-dash even without next space (for English).
Yuriy
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 4ce94415f7..7156d442bf 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1746,16 +1746,27 @@ void Paragraph::write(ostream & os, BufferParams const
& bparams,
column = 0;
break;
case '.':
+ case '!':
+ case '?':
+ case ':':
+ case ';':
+ case ',':
flushString(os, write_buffer);
if (i + 1 < size() && d->text_[i + 1] == ' ') {
- os << ".\n";
+ os << to_utf8(docstring(1, c)) << '\n';
column = 0;
} else
- os << '.';
+ os << to_utf8(docstring(1, c));
+ break;
+ case 0x2014: // — U+2014 EM DASH
+ case 0x3002: // 。 U+3002 IDEOGRAPHIC FULL STOP
+ case 0xFF0C: // ， U+FF0C FULLWIDTH COMMA
+ flushString(os, write_buffer);
+ os << to_utf8(docstring(1, c)) << '\n';
+ column = 0;
break;
default:
- if ((column > 70 && c == ' ')
- || column > 79) {
+ if (column > 500) {
flushString(os, write_buffer);
os << '\n';
column = 0;
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Semantic Linefeeds
So from your patch I see that we already did that for '.'? And in this case the \n counts as a space ? I thought our semantics was that \n did not count at all. Yes, it was already done for "." and semantics of \n (ignoring it) is the same here. Space after the "." is still added to the next line. I like the patch, but I am confused now. And what about non-european languages? I don't know much about non-European languages. Should we add some punctuation marks for them too, like "。" and "，" for Chinese? JMarc Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Semantic Linefeeds
On User Guide the difference in file size is ~2%, so yes, it can be called negligible. And after looking through User Guide, I agree with Joel that we can go without minimal line length. Also I exported User Guide to LyX 2.3 format and then successfully opened it in LyX 2.3.6. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Semantic Linefeeds
Thanks all for the feedback!
Here is a patch to try.
Should we also have minimal line length?
Yuriy
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 4ce94415f7..61a9e23c61 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1746,16 +1746,21 @@ void Paragraph::write(ostream & os, BufferParams const
& bparams,
column = 0;
break;
case '.':
+ case '!':
+ case '?':
+ case ':':
+ case ';':
+ case ',':
+ case 0x2014: // — U+2014 em-dash
flushString(os, write_buffer);
if (i + 1 < size() && d->text_[i + 1] == ' ') {
- os << ".\n";
+ os << to_utf8(docstring(1, c)) << '\n';
column = 0;
} else
- os << '.';
+ os << to_utf8(docstring(1, c));
break;
default:
- if ((column > 70 && c == ' ')
- || column > 79) {
+ if (column > 500) {
flushString(os, write_buffer);
os << '\n';
column = 0;
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Semantic Linefeeds
Hello all, What do you think about adapting semantic linefeeds (https://rhodesmill.org/brandon/2012/one-sentence-per-line/) for stored paragraph text in LyX files? Mainly to breaks lines only after the punctuation marks. Then the diffs in Git for edited documents can be much more readable. Is it worth it? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[Qt4???] Re: [PATCH] Show branches from master document in branch inset dialog
Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially considering that we will have to continue this game for 2+ years after that).
I join to your wondering. And here is the patch to at least clean
conditional code portions for Qt < 4.8.
Yuriy
From ba021353090922642e0e262db9afffd6d47e254c Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 7 Oct 2022 18:37:53 +0300
Subject: [PATCH] Remove conditional compilation portions for old Qt versions <
4.8
---
src/frontends/qt/FancyLineEdit.cpp | 4
src/frontends/qt/GuiApplication.cpp | 2 --
src/frontends/qt/GuiDocument.cpp| 2 --
src/frontends/qt/GuiFontLoader.cpp | 13 -
src/frontends/qt/GuiFontMetrics.cpp | 4
src/frontends/qt/GuiImage.cpp | 7 ---
src/frontends/qt/GuiPrefs.cpp | 4
src/frontends/qt/GuiView.cpp| 6 --
src/frontends/qt/Menus.cpp | 6 ++
9 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/src/frontends/qt/FancyLineEdit.cpp
b/src/frontends/qt/FancyLineEdit.cpp
index b9874d2e89..443094c705 100644
--- a/src/frontends/qt/FancyLineEdit.cpp
+++ b/src/frontends/qt/FancyLineEdit.cpp
@@ -19,8 +19,6 @@
#include "GuiApplication.h"
#endif
-#if QT_VERSION >= 0x040600
-
#include
#include
#include
@@ -381,6 +379,4 @@ void IconButton::animateShow(bool visible)
} // namespace lyx
-#endif // QT_VERSION >= 0x040600
-
#include "moc_FancyLineEdit.cpp"
diff --git a/src/frontends/qt/GuiApplication.cpp
b/src/frontends/qt/GuiApplication.cpp
index ff33065fe3..57293d4b84 100644
--- a/src/frontends/qt/GuiApplication.cpp
+++ b/src/frontends/qt/GuiApplication.cpp
@@ -719,7 +719,6 @@ QPixmap getPixmap(QString const & path, QString const &
name, QString const & ex
QIcon getIcon(FuncRequest const & f, bool unknown, bool rtl)
{
-#if (QT_VERSION >= 0x040600)
if (lyxrc.use_system_theme_icons) {
// use the icons from system theme that are available
QString action = toqstr(lyxaction.getActionName(f.action()));
@@ -732,7 +731,6 @@ QIcon getIcon(FuncRequest const & f, bool unknown, bool rtl)
return thmicn;
}
}
-#endif
IconInfo icondata = iconInfo(f, unknown, rtl);
if (icondata.filepath.isEmpty())
diff --git a/src/frontends/qt/GuiDocument.cpp b/src/frontends/qt/GuiDocument.cpp
index b3f31302dd..27cc39a775 100644
--- a/src/frontends/qt/GuiDocument.cpp
+++ b/src/frontends/qt/GuiDocument.cpp
@@ -1795,9 +1795,7 @@ GuiDocument::GuiDocument(GuiView & lv)
docPS->setCurrentPanel("Document Class");
// FIXME: hack to work around resizing bug in Qt >= 4.2
// bug verified with Qt 4.2.{0-3} (JSpitzm)
-#if QT_VERSION >= 0x040200
docPS->updateGeometry();
-#endif
}
diff --git a/src/frontends/qt/GuiFontLoader.cpp
b/src/frontends/qt/GuiFontLoader.cpp
index a47e555092..5ff54108bb 100644
--- a/src/frontends/qt/GuiFontLoader.cpp
+++ b/src/frontends/qt/GuiFontLoader.cpp
@@ -190,9 +190,7 @@ static bool isChosenFont(QFont & font, QString const &
family,
LYXERR_NOPOS(Debug::FONT, "got: " << fi.family());
if (fi.family().contains(family)
-#if QT_VERSION >= 0x040800
&& (style.isEmpty() || fi.styleName().contains(style))
-#endif
) {
LYXERR_NOENDL(Debug::FONT, " got it ");
return true;
@@ -220,7 +218,6 @@ QFont symbolFont(QString const & family, bool * ok)
font.setFamily(family);
}
font.setStyleStrategy(QFont::NoFontMerging);
-#if QT_VERSION >= 0x040800
font.setStyleName("LyX");
if (isChosenFont(font, family, "LyX")) {
@@ -231,7 +228,6 @@ QFont symbolFont(QString const & family, bool * ok)
LYXERR_NOENDL(Debug::FONT, "Trying normal " << family << " ... ");
font.setStyleName(QString());
-#endif
if (isChosenFont(font, family, QString())) {
LYXERR_NOPOS(Debug::FONT, "normal!");
@@ -336,15 +332,6 @@ QFont makeQFont(FontInfo const & f)
QString family =
makeFontName(toqstr(lyxrc.roman_font_name),
toqstr(lyxrc.roman_font_foundry));
font.setFamily(family);
-#ifdef Q_OS_MAC
-#if QT_VERSION >= 0x040300 //&& QT_VERSION < 0x040800
- // Workaround for a Qt bug, see
http://www.lyx.org/trac/ticket/3684
- // and
http://bugreports.qt.nokia.com/browse/QTBUG-11145.
- // FIXME: Check whether this is really fixed in Qt 4.8
- if (family == "Times" && !font.exactMatch())
- font.setFamily("Times New Roman");
-#endif
-#endif
br
Re: [PATCH] Show branches from master document in branch inset dialog
You can use branchCO->itemData(branchCO->currentIndex()).toString() This works in Qt 4 and upwards. Thanks, Jürgen! This way even dedicated Qt4 users will be able to enjoy this update :) Committed. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Show branches from master document in branch inset dialog
> Looks good. One nitpick:
>
> + if (!branchlist.find(branch)) {
> + branchCO->addItem(toqstr(branch + _("
> (master)")), toqstr(branch));
>
> I'd use boost format for this:
>
> branchCO->addItem(
> toqstr(bformat( _("%1$s[[branch]] (%2$s)[[master]]"),
>toqstr(branch), qt_("master";
>
> since with RTL scripts your precomposed string will be wrong I think.
>
> --
> Jürgen
Thanks for the suggestion, I've updated the patch.
> Looks good. One point though: for some reason, you use
QComboBox::currentData, which is only present in Qt >=5.2. This will
break Qt4.
>
>
> JMarc
Now with "(master)" suffix in combobox labels we cannot use them
directly as branch names. Is is OK to disable this for Qt4 alltogether,
as README says that LyX is only compilable on Qt4?
Yuriy
From 716cc9991d1025614424b7ceaa6761ab0f817083 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 7 Oct 2022 17:41:46 +0300
Subject: [PATCH] Show branches from master document in branch inset dialog
---
src/frontends/qt/GuiBranch.cpp | 42 +-
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/src/frontends/qt/GuiBranch.cpp b/src/frontends/qt/GuiBranch.cpp
index 24b6977390..3a1625306f 100644
--- a/src/frontends/qt/GuiBranch.cpp
+++ b/src/frontends/qt/GuiBranch.cpp
@@ -22,9 +22,13 @@
#include "insets/InsetBranch.h"
+#include "support/gettext.h"
+#include "support/lstrings.h"
+
#include
using namespace std;
+using namespace lyx::support;
namespace lyx {
namespace frontend {
@@ -40,21 +44,43 @@ GuiBranch::GuiBranch(QWidget * parent) :
InsetParamsWidget(parent)
void GuiBranch::paramsToDialog(Inset const * inset)
{
InsetBranch const * ib = static_cast(inset);
- typedef BranchList::const_iterator const_iterator;
- BranchList const & branchlist = ib->buffer().params().branchlist();
+ Buffer const & buf = ib->buffer();
+ BranchList const & branchlist = buf.params().branchlist();
docstring const cur_branch = ib->branch();
branchCO->clear();
- const_iterator const begin = branchlist.begin();
- const_iterator const end = branchlist.end();
int id = 0;
int count = 0;
- for (const_iterator it = begin; it != end; ++it, ++count) {
- docstring const & branch = it->branch();
+ for (Branch const & it : branchlist) {
+ docstring const & branch = it.branch();
+#if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
+ branchCO->addItem(toqstr(branch), toqstr(branch));
+#else
branchCO->addItem(toqstr(branch));
+#endif
if (cur_branch == branch)
id = count;
+ ++count;
+ }
+#if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
+ // Add branches from master
+ Buffer const * masterBuf = buf.masterBuffer();
+ if (masterBuf != &buf) {
+ BranchList const & masterBranchlist =
masterBuf->params().branchlist();
+ for (Branch const & it : masterBranchlist) {
+ docstring const & branch = it.branch();
+ if (!branchlist.find(branch)) {
+ branchCO->addItem(
+ toqstr(bformat(_("%1$s[[branch]]
(%2$s)[[master]]"),
+ branch, _("master"))),
+ toqstr(branch));
+ if (cur_branch == branch)
+ id = count;
+ ++count;
+ }
+ }
}
+#endif
branchCO->setCurrentIndex(id);
invertedCB->setChecked(ib->params().inverted);
}
@@ -62,7 +88,11 @@ void GuiBranch::paramsToDialog(Inset const * inset)
docstring GuiBranch::dialogToParams() const
{
+#if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
+ InsetBranchParams
params(qstring_to_ucs4(branchCO->currentData().toString()),
invertedCB->isChecked());
+#else
InsetBranchParams params(qstring_to_ucs4(branchCO->currentText()),
invertedCB->isChecked());
+#endif
return from_utf8(InsetBranch::params2string(params));
}
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Show branches from master document in branch inset dialog
Hello all,
Currently in LyX you can insert into child documents the insets for
branches defined in master document only. But it is impossible to change
the branch afterwards for such inset because master branches are not
shown in the "Branch Settings" dialog.
The attached patch fixes this.
Yuriy
From e46a33c41625bc7ca49df53a8bf14997c318f92d Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 6 Oct 2022 20:24:59 +0300
Subject: [PATCH] Show branches from master document in branch inset dialog
---
src/frontends/qt/GuiBranch.cpp | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/frontends/qt/GuiBranch.cpp b/src/frontends/qt/GuiBranch.cpp
index 24b6977390..94172b7967 100644
--- a/src/frontends/qt/GuiBranch.cpp
+++ b/src/frontends/qt/GuiBranch.cpp
@@ -22,6 +22,8 @@
#include "insets/InsetBranch.h"
+#include "support/gettext.h"
+
#include
using namespace std;
@@ -40,20 +42,33 @@ GuiBranch::GuiBranch(QWidget * parent) :
InsetParamsWidget(parent)
void GuiBranch::paramsToDialog(Inset const * inset)
{
InsetBranch const * ib = static_cast(inset);
- typedef BranchList::const_iterator const_iterator;
- BranchList const & branchlist = ib->buffer().params().branchlist();
+ Buffer const & buf = ib->buffer();
+ BranchList const & branchlist = buf.params().branchlist();
docstring const cur_branch = ib->branch();
branchCO->clear();
- const_iterator const begin = branchlist.begin();
- const_iterator const end = branchlist.end();
int id = 0;
int count = 0;
- for (const_iterator it = begin; it != end; ++it, ++count) {
- docstring const & branch = it->branch();
- branchCO->addItem(toqstr(branch));
+ for (Branch const & it : branchlist) {
+ docstring const & branch = it.branch();
+ branchCO->addItem(toqstr(branch), toqstr(branch));
if (cur_branch == branch)
id = count;
+ ++count;
+ }
+ // Add branches from master
+ Buffer const * masterBuf = buf.masterBuffer();
+ if (masterBuf != &buf) {
+ BranchList const & masterBranchlist =
masterBuf->params().branchlist();
+ for (Branch const & it : masterBranchlist) {
+ docstring const & branch = it.branch();
+ if (!branchlist.find(branch)) {
+ branchCO->addItem(toqstr(branch + _("
(master)")), toqstr(branch));
+ if (cur_branch == branch)
+ id = count;
+ ++count;
+ }
+ }
}
branchCO->setCurrentIndex(id);
invertedCB->setChecked(ib->params().inverted);
@@ -62,7 +77,7 @@ void GuiBranch::paramsToDialog(Inset const * inset)
docstring GuiBranch::dialogToParams() const
{
- InsetBranchParams params(qstring_to_ucs4(branchCO->currentText()),
invertedCB->isChecked());
+ InsetBranchParams
params(qstring_to_ucs4(branchCO->currentData().toString()),
invertedCB->isChecked());
return from_utf8(InsetBranch::params2string(params));
}
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
Riki, is it OK to have this also in stable? Yuriy ping... -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
LyX 2.4.0
Things got a bit crazy again, but I now should have a bit of time. Where do people think we stand with 2.4.0? I've seen a bit of activity in the interim. Do we need to do one more alpha? Or should we proceed directly to beta 1? What if anything needs to be done before we move to whatever the next stage is? Riki I'm working on implementing branch expressions that was discussed here: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg216485.html Seems like this can be done even without file format change, so it can go/backport to 2.4 later. Also I support the "unpopular proposal" from Jean-Marc. LyX is frequently used for highly-structured documents with large insets and improvements in breakrows branch would be very desirable in new version. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Latex run after toggling search pane
Hello, In current master I'm getting automatic run of latex after toggling Find and replace button on the toolbar. Bisect gives this commit: bca1b63d89e27b. Jürgen, can you check this? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
Sounds reasonable to me. Riki Riki, is it OK to have this also in stable? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
Sounds reasonable to me. Riki Thanks Riki. So I've committed the patch after updating the docs about this change. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
Done in the attached patch. Now just with adding "~" to inverted insets, I think it is more visible than "!". Yuriy I've checked implementing the additional color change. But to retain LyX flexibility, just adding the "inverted branch label" color to the table and overriding labelColor method will be not enough. We'll also have to define a new property for layouts, something like "InactiveLabelFont". So probably it is not worth it. Also after usage of the patch for several days, I can say that adding only an inversion symbol works well for distinguishing inverted branch insets. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Adding LFUN for removing LyX modules
Note that it is best to move the test for removing the module in getStatus, so
that the function is disabled. With that, it would become possible in the
frontend to use that code. I do not like to have duplicated (and possibly
different) logic in those places. The solution might be to have a temporary
module list in GuiDocument and call the methods of this this instance to handle
the dialogs (the code uses the widgets as data structure now).
JMarc
Thanks for the suggestions, Jean-Marc. Moved the check there. Probably
it is worth to do the same for layoutModuleCanBeAdded, right? As I see
now, the check for removing modules in frontend (updateDelPB) is more
complex. Is that additional check really necessary? With current LyX
built-in modules situation handled there is impossible.
Cosmetics, but please add * \li Origin here... Pavel
Ok, added.
Yuriy
From 8cc029d13a0a6f44e87ccc71f7a3bc33f7d438ff Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 22 Oct 2021 23:59:58 +0300
Subject: [PATCH] Add LFUN for removing LyX modules
---
src/BufferParams.cpp | 6 ++
src/BufferParams.h | 2 ++
src/BufferView.cpp | 28 +++-
src/FuncCode.h | 1 +
src/LayoutModuleList.h | 2 ++
src/LyXAction.cpp | 11 +++
6 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index bbbce16bef..a14e3211f9 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -2608,6 +2608,12 @@ bool BufferParams::addLayoutModule(string const &
modName)
}
+void BufferParams::removeLayoutModule(string const & modName)
+{
+ layout_modules_.remove(modName);
+}
+
+
string BufferParams::bufferFormat() const
{
return documentClass().outputFormat();
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 52d8219cb4..3a40be60a0 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -175,6 +175,8 @@ public:
/// if you want to check for compatibility.
/// \return true if module was successfully added.
bool addLayoutModule(std::string const & modName);
+ ///
+ void removeLayoutModule(std::string const & modName);
/// checks to make sure module's requriements are satisfied, that it
does
/// not conflict with already-present modules, isn't already loaded,
etc.
bool layoutModuleCanBeAdded(std::string const & modName) const;
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index ac9a8235db..d9337eff52 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -36,6 +36,7 @@
#include "lyxfind.h"
#include "LyXRC.h"
#include "MetricsInfo.h"
+#include "ModuleList.h"
#include "Paragraph.h"
#include "Session.h"
#include "Text.h"
@@ -1161,7 +1162,20 @@ bool BufferView::getStatus(FuncRequest const & cmd,
FuncStatus & flag)
case LFUN_TEXTCLASS_LOAD:
flag.setEnabled(!buffer_.isReadonly());
break;
-
+ case LFUN_LAYOUT_MODULE_REMOVE: {
+ string const modName = to_ascii(cmd.argument());
+ bool hasDependentModules = false;
+ LayoutModuleList const mods = buffer().params().getModules();
+ for (string const & mod : mods) {
+ vector const reqs =
theModuleList[mod]->getRequiredModules();
+ if (find(reqs.begin(), reqs.end(), modName) !=
reqs.end()) {
+ hasDependentModules = true;
+ break;
+ }
+ }
+ flag.setEnabled(!buffer_.isReadonly() && !hasDependentModules);
+ break;
+ }
case LFUN_UNDO:
// We do not use the LyXAction flag for readonly because Undo
sets the
// buffer clean/dirty status by itself.
@@ -1400,6 +1414,18 @@ void BufferView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
break;
}
+ case LFUN_LAYOUT_MODULE_REMOVE: {
+ // FIXME: this modifies the document in
cap::switchBetweenClasses
+ // without calling recordUndo. Fix this before using
+ // recordUndoBufferParams().
+ cur.recordUndoFullBuffer();
+ buffer_.params().removeLayoutModule(argument);
+ makeDocumentClass();
+ dr.screenUpdate(Update::Force);
+ dr.forceBufferUpdate();
+ break;
+ }
+
case LFUN_TEXTCLASS_APPLY: {
// since this shortcircuits, the second call is made only if
// the first fails
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 20231eb164..2a3221641d 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -502,6 +502,7 @@ enum FuncCode
LFUN_SPELLING_REMOVE_LOCAL, // jspitzm 202
Re: [PATCH] Adding LFUN for removing LyX modules
I like this idea! What if layout-module-remove is used on a module that
a different module depends on? e.g., AMS Theorems (Extended) depends on
AMS Theorems. If I have both added and I try to remove AMS Theorems,
what happens? Do we need a layoutModuleCanBeRemoved helper function?
Actually there must already be some code because "delete" is greyed out
if I do this in the GUI.
Scott
You are right, module dependencies were not taken into account in first
version of the patch. Here is the updated patch that forbids removing
modules that have dependents.
Yuriy
From f62034cbd7ed6469f20a2605a965074817e8d270 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 22 Oct 2021 02:30:06 +0300
Subject: [PATCH] Add LFUN for removing LyX modules
---
src/BufferParams.cpp | 12
src/BufferParams.h | 4
src/BufferView.cpp | 19 +++
src/FuncCode.h | 1 +
src/LayoutModuleList.cpp | 12
src/LayoutModuleList.h | 5 +
src/LyXAction.cpp| 10 ++
7 files changed, 63 insertions(+)
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index bbbce16bef..90f52a38fb 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -2580,6 +2580,12 @@ bool BufferParams::layoutModuleCanBeAdded(string const &
modName) const
}
+bool BufferParams::layoutModuleCanBeRemoved(string const & modName) const
+{
+ return layout_modules_.moduleCanBeRemoved(modName, baseClass());
+}
+
+
docstring BufferParams::getLocalLayout(bool forced) const
{
if (forced)
@@ -2608,6 +2614,12 @@ bool BufferParams::addLayoutModule(string const &
modName)
}
+void BufferParams::removeLayoutModule(string const & modName)
+{
+ layout_modules_.remove(modName);
+}
+
+
string BufferParams::bufferFormat() const
{
return documentClass().outputFormat();
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 52d8219cb4..fb9364f333 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -175,10 +175,14 @@ public:
/// if you want to check for compatibility.
/// \return true if module was successfully added.
bool addLayoutModule(std::string const & modName);
+ ///
+ void removeLayoutModule(std::string const & modName);
/// checks to make sure module's requriements are satisfied, that it
does
/// not conflict with already-present modules, isn't already loaded,
etc.
bool layoutModuleCanBeAdded(std::string const & modName) const;
///
+ bool layoutModuleCanBeRemoved(std::string const & modName) const;
+ ///
void addRemovedModule(std::string const & modName)
{ removed_modules_.push_back(modName); }
/// Clear the list
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index ac9a8235db..e4fc04df4d 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -1156,6 +1156,7 @@ bool BufferView::getStatus(FuncRequest const & cmd,
FuncStatus & flag)
case LFUN_BUFFER_PARAMS_APPLY:
case LFUN_LAYOUT_MODULES_CLEAR:
case LFUN_LAYOUT_MODULE_ADD:
+ case LFUN_LAYOUT_MODULE_REMOVE:
case LFUN_LAYOUT_RELOAD:
case LFUN_TEXTCLASS_APPLY:
case LFUN_TEXTCLASS_LOAD:
@@ -1400,6 +1401,24 @@ void BufferView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
break;
}
+ case LFUN_LAYOUT_MODULE_REMOVE: {
+ BufferParams const & params = buffer_.params();
+ if (!params.layoutModuleCanBeRemoved(argument)) {
+ LYXERR0("Module `" << argument <<
+ "' cannot be removed, it is required by another
active module.");
+ break;
+ }
+ // FIXME: this modifies the document in
cap::switchBetweenClasses
+ // without calling recordUndo. Fix this before using
+ // recordUndoBufferParams().
+ cur.recordUndoFullBuffer();
+ buffer_.params().removeLayoutModule(argument);
+ makeDocumentClass();
+ dr.screenUpdate(Update::Force);
+ dr.forceBufferUpdate();
+ break;
+ }
+
case LFUN_TEXTCLASS_APPLY: {
// since this shortcircuits, the second call is made only if
// the first fails
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 20231eb164..2a3221641d 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -502,6 +502,7 @@ enum FuncCode
LFUN_SPELLING_REMOVE_LOCAL, // jspitzm 20210307
LFUN_FINISHED_DOWN, // lasgouttes 20210629
LFUN_FINISHED_UP, // lasgouttes 20210629
+ LFUN_LAYOUT_MODULE_REMOVE, // yuriy 20211021
LFUN_LASTACTION // end of the table
};
diff --git a/src/LayoutModul
Re: Marking inverted branch insets
I tried to do something a year ago, and my plan then was to strikeout the branch name. Unfortunately, it is not possible to do now, unless we can set he label as html (didn't try). JMarc There is another way to get strikeout text -- Unicode. I tried it with some copied text from https://yaytext.com/strike/, but its rendering by Qt in LyX is not so good. I agree that for most people (who don't know Boolean algebra) strikeout can be the most understandable indication for inversion. So, is this patch OK to commit to have acceptable solution for now? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Adding LFUN for removing LyX modules
Now LyX has functions for adding one module (LFUN_LAYOUT_MODULE_ADD) and
for removing all modules (LFUN_LAYOUT_MODULES_CLEAR), but removing only
one module is impossible. I propose to add such function:
LFUN_LAYOUT_MODULE_REMOVE.
My current use case: adding and removing module "Minimalistic Insets" to
unclutter document with many branch insets by hiding their labels during
work on content.
Without such LFUN this should be done manually. With it we will be able
to do:
layout-module-add minimalistic
layout-module-remove minimalistic
YuriyFrom d9f6b76582f665e7f53e165588ff1d530c330df5 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 21 Oct 2021 18:50:49 +0300
Subject: [PATCH] Add LFUN for removing LyX modules
---
src/BufferParams.cpp | 6 ++
src/BufferParams.h | 2 ++
src/BufferView.cpp | 13 +
src/FuncCode.h | 1 +
src/LayoutModuleList.h | 2 ++
src/LyXAction.cpp | 10 ++
6 files changed, 34 insertions(+)
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index bbbce16bef..a14e3211f9 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -2608,6 +2608,12 @@ bool BufferParams::addLayoutModule(string const &
modName)
}
+void BufferParams::removeLayoutModule(string const & modName)
+{
+ layout_modules_.remove(modName);
+}
+
+
string BufferParams::bufferFormat() const
{
return documentClass().outputFormat();
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 52d8219cb4..3a40be60a0 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -175,6 +175,8 @@ public:
/// if you want to check for compatibility.
/// \return true if module was successfully added.
bool addLayoutModule(std::string const & modName);
+ ///
+ void removeLayoutModule(std::string const & modName);
/// checks to make sure module's requriements are satisfied, that it
does
/// not conflict with already-present modules, isn't already loaded,
etc.
bool layoutModuleCanBeAdded(std::string const & modName) const;
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index ac9a8235db..fead2c3683 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -1156,6 +1156,7 @@ bool BufferView::getStatus(FuncRequest const & cmd,
FuncStatus & flag)
case LFUN_BUFFER_PARAMS_APPLY:
case LFUN_LAYOUT_MODULES_CLEAR:
case LFUN_LAYOUT_MODULE_ADD:
+ case LFUN_LAYOUT_MODULE_REMOVE:
case LFUN_LAYOUT_RELOAD:
case LFUN_TEXTCLASS_APPLY:
case LFUN_TEXTCLASS_LOAD:
@@ -1400,6 +1401,18 @@ void BufferView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
break;
}
+ case LFUN_LAYOUT_MODULE_REMOVE: {
+ // FIXME: this modifies the document in
cap::switchBetweenClasses
+ // without calling recordUndo. Fix this before using
+ // recordUndoBufferParams().
+ cur.recordUndoFullBuffer();
+ buffer_.params().removeLayoutModule(argument);
+ makeDocumentClass();
+ dr.screenUpdate(Update::Force);
+ dr.forceBufferUpdate();
+ break;
+ }
+
case LFUN_TEXTCLASS_APPLY: {
// since this shortcircuits, the second call is made only if
// the first fails
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 20231eb164..2a3221641d 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -502,6 +502,7 @@ enum FuncCode
LFUN_SPELLING_REMOVE_LOCAL, // jspitzm 20210307
LFUN_FINISHED_DOWN, // lasgouttes 20210629
LFUN_FINISHED_UP, // lasgouttes 20210629
+ LFUN_LAYOUT_MODULE_REMOVE, // yuriy 20211021
LFUN_LASTACTION // end of the table
};
diff --git a/src/LayoutModuleList.h b/src/LayoutModuleList.h
index 868c1cf945..1c65ae8564 100644
--- a/src/LayoutModuleList.h
+++ b/src/LayoutModuleList.h
@@ -51,6 +51,8 @@ public:
///
void push_back(std::string const & str) { lml_.push_back(str); }
///
+ void remove(std::string const & str) { lml_.remove(str); }
+ ///
size_t size() const { return lml_.size(); }
/// This is needed in GuiDocument. It seems better than an
/// implicit conversion.
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 254060e789..e2d6cd3cca 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -2477,6 +2477,16 @@ void LyXAction::init()
*/
{ LFUN_LAYOUT_MODULE_ADD, "layout-module-add", NoInternal,
Layout },
+/*!
+ * \var lyx::FuncCode lyx::LFUN_LAYOUT_MODULE_REMOVE
+ * \li Action: Removes a module.
+ * \li Notion: Removes a module from the list of included modules for the
current buffer.
+ * \li Syntax: layout-module-remove
+ * \li Params: : the module to be removed
+ * \endvar
+ */
+
Re: Marking inverted branch insets
Good question. Indeed I have used nested branches until now. But I find
the nesting annoying, and I always have to pause to think what should I
nest in what? But thinking about it more, perhaps your proposed feature
would work for what I want. I don't have much time to think about this
more now, but I do like that we're having this discussion. Perhaps we
should write down a few use cases that would motivte which features we
consider.
Scott
My use case: product documentation with differences for its many
modifications and versions.
I also think this could be useful. Probably not for 2.4, though. (I'll be
emailing about that soon.) But improving the visuals for inversion, etc, can be
done right away.
Done in the attached patch. Now just with adding "~" to inverted insets,
I think it is more visible than "!".
A related thing some people have wanted is for LyX to output a LaTeX
conditional depending upon branches. So e.g. we'd have:
\newif\LyXBranchName
\LyXBranchNametrue
if the branch is active, and the obvious alternative otherwise. In that case,
we could also offer the option of outputting all branches to LaTeX, but
conditionalizing them this way.
Riki
Yes, this way LaTeX export result will be closer to LyX source.
Yuriy
From 1718590f4cc7066ba882a4cffbfc8b5f19cb6dd0 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 21 Oct 2021 12:56:05 +0300
Subject: [PATCH] Mark inverted branch insets
---
src/insets/InsetBranch.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/insets/InsetBranch.cpp b/src/insets/InsetBranch.cpp
index 2920204fe2..69af670d39 100644
--- a/src/insets/InsetBranch.cpp
+++ b/src/insets/InsetBranch.cpp
@@ -110,8 +110,10 @@ docstring const InsetBranch::buttonLabel(BufferView const
&) const
if (inchild && master_selected != child_selected)
symb += (child_selected ? tick : cross);
+docstring inv_symb = from_ascii(params_.inverted ? "~" : "");
+
if (decoration() == InsetDecoration::MINIMALISTIC)
- return symb + params_.branch;
+ return symb + inv_symb + params_.branch;
docstring s;
if (inmaster && inchild)
@@ -122,7 +124,7 @@ docstring const InsetBranch::buttonLabel(BufferView const
&) const
s = _("Branch (master): ");
else // !inmaster && !inchild
s = _("Branch (undefined): ");
- s += params_.branch;
+ s += inv_symb + params_.branch;
return symb + s;
}
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
On 20.10.2021 17:20, Thibaut Cuvelier wrote: On Wed, 20 Oct 2021 at 16:07, Yuriy Skalko <mailto:yuriy.ska...@gmail.com>> wrote: >> Really I'm also thinking about more flexible system -- to connect branch >> insets to branches using logical expressions. So the branch inset could have >> logical combination of existing branches, not just branch name with optional >> inversion. For example now it is impossible to have a part of the document >> that will be outputted when any of 2 branches is active. But with logical >> expressions we will have inset "FirstBranch or SecondBranch" that solves >> this task. More complex combinations also will be possible. > > I like this idea a lot. I would also be interested in a dependency > structure of branches (i.e., not variable by insets) along the lines of > "branch Q depends on branch C and branch D so to activate branch Q, > branches C and D must also be activated". I think we should think hard > about exactly what features we want and the interface. Ideally we would > extend the current functionality without making the interface much more > complex for most users who I think do not use branches in the way you > and I have in mind. > > Best, > Scott Really logical AND operation on branches can be implemented now by nesting insets. Do you want to get separate Q to get simpler expressions/insets in other places in the document? Of course I agree that simple usage of branches should remain simple. FWIW, UI requirements for this kind of feature are not unique to LyX, XML authoring tools typically have to deal with conditional text/profiling. For instance, Oxygen XML and XMLmind have some UI for this (but it focuses on showing the attributes that are used to filter out some content, i.e. it shows the elements that the user can use to write their own logic to select the content to output): https://www.oxygenxml.com/doc/versions/24.0/ug-editor/topics/preferences-profiling-conditions.html <https://www.oxygenxml.com/doc/versions/24.0/ug-editor/topics/preferences-profiling-conditions.html> and https://www.xmlmind.com/xmleditor/_distrib/doc/profiling/index.html <https://www.xmlmind.com/xmleditor/_distrib/doc/profiling/index.html> Thibaut, Do you mean interface similar to Figure 2 here? https://www.xmlmind.com/xmleditor/_distrib/doc/profiling/the_solutions.html I cannot find screenshots of Oxygen XML on their site. Is it similar? Maybe simple solution will work: Now branch inset dialog allows choosing branch and setting inversion. I propose to add radiobuttons: Basic and Advanced and leave existing settings in Basic part. The Advanced part will contain just edit field for logic expression on existing branch names. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Marking inverted branch insets
I'm working on the highly variative document that contains many branches frequently changing their states. And it is not very convenient because it is impossible to see immediately if current branch inset is inverted or not. Have you experienced such issue? What do you think about marking inverted insets in some way? Maybe darker/different label color? Or some additional symbol like "!"? I have experienced this also. I think using a symbol is better for accessibility reasons. Perhaps additionally changing the color could be considered as well. Thanks for fast reply, Scott! I'm glad to know that it is not only my problem. Really I'm also thinking about more flexible system -- to connect branch insets to branches using logical expressions. So the branch inset could have logical combination of existing branches, not just branch name with optional inversion. For example now it is impossible to have a part of the document that will be outputted when any of 2 branches is active. But with logical expressions we will have inset "FirstBranch or SecondBranch" that solves this task. More complex combinations also will be possible. I like this idea a lot. I would also be interested in a dependency structure of branches (i.e., not variable by insets) along the lines of "branch Q depends on branch C and branch D so to activate branch Q, branches C and D must also be activated". I think we should think hard about exactly what features we want and the interface. Ideally we would extend the current functionality without making the interface much more complex for most users who I think do not use branches in the way you and I have in mind. Best, Scott Really logical AND operation on branches can be implemented now by nesting insets. Do you want to get separate Q to get simpler expressions/insets in other places in the document? Of course I agree that simple usage of branches should remain simple. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Marking inverted branch insets
Hi all, I'm working on the highly variative document that contains many branches frequently changing their states. And it is not very convenient because it is impossible to see immediately if current branch inset is inverted or not. Have you experienced such issue? What do you think about marking inverted insets in some way? Maybe darker/different label color? Or some additional symbol like "!"? Really I'm also thinking about more flexible system -- to connect branch insets to branches using logical expressions. So the branch inset could have logical combination of existing branches, not just branch name with optional inversion. For example now it is impossible to have a part of the document that will be outputted when any of 2 branches is active. But with logical expressions we will have inset "FirstBranch or SecondBranch" that solves this task. More complex combinations also will be possible. Best Regards, Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patch review
Older gcc will have problem:
make[6]: Entering directory '/root/lyx/src/frontends/qt'
CXX ColorCache.o
CXX GuiBibtex.o
GuiBibtex.cpp: In member function 'void
lyx::frontend::GuiBibtex::setFileEncodings(const
std::__debug::vector,
std::allocator > >&)':
GuiBibtex.cpp:529:44: error: conversion from 'int' to 'Qt::MatchFlags {aka
QFlags}' is ambiguous
Qt::MatchExactly | Qt::MatchWrap);
> ...
Pavel
Thanks for testing, Pavel. I've had a suspicion to this part with bit
operators. I've removed it in the updated patch.
Besides the problems reported by Pavel (which I can reproduce even in C++17
mode with gcc 5.5), I like the patch.
How confident are we that gcc is right when it says that 'T(foo)' is equivalent
to 'foo' when foo is of type 'T'?
JMarc
I skipped messages related to `char_type` since that can be defined
differently on different systems. The rest should be OK.
Yuriy
From 04db31562072528a5d5ae05a01b999a3026e208d Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Wed, 29 Sep 2021 12:49:21 +0300
Subject: [PATCH] Remove useless casts reported by GCC with -Wuseless-cast
option
---
src/BiblioInfo.cpp| 2 +-
src/Buffer.cpp| 2 +-
src/Converter.cpp | 2 +-
src/LaTeX.cpp | 2 +-
src/ParIterator.cpp | 6 +++---
src/frontends/qt/ColorCache.cpp | 2 +-
src/frontends/qt/GuiBox.cpp | 2 +-
src/frontends/qt/GuiDocument.cpp | 6 +++---
src/frontends/qt/GuiExternal.cpp | 2 +-
src/frontends/qt/GuiMathMatrix.cpp| 4 ++--
src/frontends/qt/GuiPrefs.cpp | 2 +-
src/frontends/qt/GuiSendto.cpp| 2 +-
src/frontends/qt/GuiView.cpp | 4 ++--
src/frontends/qt/Menus.cpp| 6 ++
src/insets/InsetGraphics.cpp | 2 +-
src/insets/InsetIPAMacro.cpp | 4 ++--
src/insets/InsetTabular.cpp | 16
src/mathed/InsetMathMacroTemplate.cpp | 2 +-
18 files changed, 33 insertions(+), 35 deletions(-)
diff --git a/src/BiblioInfo.cpp b/src/BiblioInfo.cpp
index 85c3e884d9..638579a752 100644
--- a/src/BiblioInfo.cpp
+++ b/src/BiblioInfo.cpp
@@ -1402,7 +1402,7 @@ docstring const BiblioInfo::getInfo(docstring const & key,
{
BiblioInfo::const_iterator it = find(key);
if (it == end())
- return docstring(_("Bibliography entry not found!"));
+ return _("Bibliography entry not found!");
BibTeXInfo const & data = it->second;
BibTeXInfoList xrefptrs;
for (docstring const & xref : getXRefs(data)) {
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index b2aaf18535..99d844b615 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -3825,7 +3825,7 @@ void Buffer::Impl::updateMacros(DocIterator & it,
DocIterator & scope)
// FIXME (Abdel), I don't understand why we pass 'it'
here
// instead of 'macroTemplate' defined above... is this
correct?
macros[macroTemplate.name()][it] =
- Impl::ScopeMacro(scope,
MacroData(const_cast(owner_), it));
+ Impl::ScopeMacro(scope, MacroData(owner_, it));
}
// next paragraph
diff --git a/src/Converter.cpp b/src/Converter.cpp
index b4340c8f52..4e9a2ad426 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -853,7 +853,7 @@ Converters::RetVal Converters::runLaTeX(Buffer const &
buffer, string const & co
// do the LaTeX run(s)
string const name = buffer.latexName();
- LaTeX latex(command, runparams, FileName(makeAbsPath(name)),
+ LaTeX latex(command, runparams, makeAbsPath(name),
buffer.filePath(), buffer.layoutPos(),
buffer.isClone(), buffer.freshStartRequired());
TeXErrors terr;
diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp
index 6e7fe921b8..a8d14b1f74 100644
--- a/src/LaTeX.cpp
+++ b/src/LaTeX.cpp
@@ -795,7 +795,7 @@ int LaTeX::scanLogFile(TeXErrors & terr)
string tmp =
onlyFileName(changeExtension(file.absFileName(), ".log"));
LYXERR(Debug::LATEX, "Log file: " << tmp);
- FileName const fn = FileName(makeAbsPath(tmp));
+ FileName const fn = makeAbsPath(tmp);
// FIXME we should use an ifdocstream here and a docstring for token
// below. The encoding of the log file depends on the _output_ (font)
// encoding of the TeX file (T1, TU etc.). See #10728.
diff --git a/src/ParIterator.cpp b/src/ParIterator.cpp
index 7289889360..10de5f312d 100644
--- a/src/ParIterator.cpp
+++ b/src/ParIterator.cpp
@@ -69,7 +69,7 @@ ParIterator & ParIterator::operator--()
Paragraph & ParIterato
Patch review
Hi all,
I've recently compiled LyX with latest version of GCC and used several
useful diagnostic options. Two simpler patches are already committed,
but the third one is bigger and worth additional checkup -- it is in
attachment.
Best Regards,
Yuriy
From 6e2fb6f86550186881838f7020a1535e4fdffbb7 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Tue, 28 Sep 2021 20:13:42 +0300
Subject: [PATCH] Remove useless casts reported by GCC with -Wuseless-cast
option
---
src/BiblioInfo.cpp| 2 +-
src/Buffer.cpp| 2 +-
src/Converter.cpp | 2 +-
src/KeyMap.cpp| 2 +-
src/LaTeX.cpp | 2 +-
src/ParIterator.cpp | 6 +++---
src/frontends/qt/ColorCache.cpp | 2 +-
src/frontends/qt/GuiBibtex.cpp| 2 +-
src/frontends/qt/GuiBox.cpp | 2 +-
src/frontends/qt/GuiCitation.cpp | 4 ++--
src/frontends/qt/GuiDocument.cpp | 6 +++---
src/frontends/qt/GuiExternal.cpp | 2 +-
src/frontends/qt/GuiMathMatrix.cpp| 4 ++--
src/frontends/qt/GuiPrefs.cpp | 12 ++--
src/frontends/qt/GuiSendto.cpp| 2 +-
src/frontends/qt/GuiView.cpp | 4 ++--
src/frontends/qt/Menus.cpp| 6 ++
src/frontends/qt/TocModel.cpp | 2 +-
src/frontends/qt/TocWidget.cpp| 2 +-
src/insets/InsetGraphics.cpp | 2 +-
src/insets/InsetIPAMacro.cpp | 4 ++--
src/insets/InsetTabular.cpp | 16
src/mathed/InsetMathMacroTemplate.cpp | 2 +-
23 files changed, 44 insertions(+), 46 deletions(-)
diff --git a/src/BiblioInfo.cpp b/src/BiblioInfo.cpp
index 85c3e884d9..638579a752 100644
--- a/src/BiblioInfo.cpp
+++ b/src/BiblioInfo.cpp
@@ -1402,7 +1402,7 @@ docstring const BiblioInfo::getInfo(docstring const & key,
{
BiblioInfo::const_iterator it = find(key);
if (it == end())
- return docstring(_("Bibliography entry not found!"));
+ return _("Bibliography entry not found!");
BibTeXInfo const & data = it->second;
BibTeXInfoList xrefptrs;
for (docstring const & xref : getXRefs(data)) {
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 457aa43225..a713f8dd55 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -3827,7 +3827,7 @@ void Buffer::Impl::updateMacros(DocIterator & it,
DocIterator & scope)
// FIXME (Abdel), I don't understand why we pass 'it'
here
// instead of 'macroTemplate' defined above... is this
correct?
macros[macroTemplate.name()][it] =
- Impl::ScopeMacro(scope,
MacroData(const_cast(owner_), it));
+ Impl::ScopeMacro(scope, MacroData(owner_, it));
}
// next paragraph
diff --git a/src/Converter.cpp b/src/Converter.cpp
index b4340c8f52..4e9a2ad426 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -853,7 +853,7 @@ Converters::RetVal Converters::runLaTeX(Buffer const &
buffer, string const & co
// do the LaTeX run(s)
string const name = buffer.latexName();
- LaTeX latex(command, runparams, FileName(makeAbsPath(name)),
+ LaTeX latex(command, runparams, makeAbsPath(name),
buffer.filePath(), buffer.layoutPos(),
buffer.isClone(), buffer.freshStartRequired());
TeXErrors terr;
diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
index f469da5c44..6b55b8e20e 100644
--- a/src/KeyMap.cpp
+++ b/src/KeyMap.cpp
@@ -439,7 +439,7 @@ FuncRequest const & KeyMap::lookup(KeySymbol const &key,
Table::const_iterator end = table.end();
for (Table::const_iterator cit = table.begin(); cit != end; ++cit) {
KeyModifier mask = cit->mod.second;
- KeyModifier check = static_cast(mod & ~mask);
+ KeyModifier check = mod & ~mask;
if (cit->code == key && cit->mod.first == check) {
// match found
diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp
index 6e7fe921b8..a8d14b1f74 100644
--- a/src/LaTeX.cpp
+++ b/src/LaTeX.cpp
@@ -795,7 +795,7 @@ int LaTeX::scanLogFile(TeXErrors & terr)
string tmp =
onlyFileName(changeExtension(file.absFileName(), ".log"));
LYXERR(Debug::LATEX, "Log file: " << tmp);
- FileName const fn = FileName(makeAbsPath(tmp));
+ FileName const fn = makeAbsPath(tmp);
// FIXME we should use an ifdocstream here and a docstring for token
// below. The encoding of the log file depends on the _output_ (font)
// encoding of the TeX file (T1, TU etc.). See #10728.
diff --git a/src/ParIterator.cpp b/src/ParIterator.cpp
index 7289889360..10de5f312d 100644
--- a/src/ParIterator.cpp
+++
Re: LatexType values
On 28.07.2021 4:33, Richard Kimberly Heck wrote: On 7/27/21 4:19 PM, Yuriy Skalko wrote: Hello all, When I'm defining simple custom inset (in Local Layout): InsetLayout Flex:BoxInset LyxType custom LabelString Box LatexType Paragraph Decoration Classic End I'm getting this error: insets/InsetLayout.cpp (283): Unknown LaTeXType `Paragraph'. But according to Customization manual this is valid value for LaTeXType! I think the manual must be wrong. The "none" case, which is valid, probably does what you want Paragraph to do, i.e., it just outputs the contents of the inset without any surrounding LaTeX stuff. Riki Thanks Riki, Yes, the "None" works here. Really LatexType property for flex insets is also described in manual with correct allowable values (and Paragraph can be used only in paragraph styles), but unlike many other properties that can have same values for both paragraph styles and flex insets, this one has such subtle difference. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
LatexType values
Hello all,
When I'm defining simple custom inset (in Local Layout):
InsetLayout Flex:BoxInset
LyxType custom
LabelString Box
LatexType Paragraph
DecorationClassic
End
I'm getting this error:
insets/InsetLayout.cpp (283): Unknown LaTeXType `Paragraph'.
But according to Customization manual this is valid value for LaTeXType!
Looking into the sources (InsetLayout.cpp), the translation function
processes only 3 values, not 6 values as described in manual:
InsetLaTeXType translateLaTeXType(std::string const & str)
{
if (compare_ascii_no_case(str, "command") == 0)
return InsetLaTeXType::COMMAND;
if (compare_ascii_no_case(str, "environment") == 0)
return InsetLaTeXType::ENVIRONMENT;
if (compare_ascii_no_case(str, "none") == 0)
return InsetLaTeXType::NOLATEXTYPE;
return InsetLaTeXType::ILT_ERROR;
}
So the question is: should InsetLaTeXType enum (from InsetLayout.h) be
aligned with LatexType enum (from LayoutEnums.h)? Or even keep only one
of them?
enum class InsetLaTeXType : int {
NOLATEXTYPE,
COMMAND,
ENVIRONMENT,
ILT_ERROR
};
enum LatexType {
///
LATEX_PARAGRAPH = 1,
///
LATEX_COMMAND,
///
LATEX_ENVIRONMENT,
///
LATEX_ITEM_ENVIRONMENT,
///
LATEX_BIB_ENVIRONMENT,
///
LATEX_LIST_ENVIRONMENT
};
Best Regards,
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Labels from inactive branches
Hi all, I'm working on a document with several branches that have many duplicated labels. Now all these labels are shown in the Cross-reference dialog and it doesn't matter if a branch is active or not (duplicated labels have "DUPLICATE:" prefix). It would be much more convenient to see labels only from active branch(es). As I understand, now it is impossible to hide labels from inactive branches in the Available Labels list in Cross-reference dialog. Will it be Ok if I'll work on this change and prepare the patch? Best Regards, Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Reduce the amount of needed boost headers
> By the way, when you are already digging into the internal workings of > preview loader, would it be hard to allow mutliple threads loading > graphics images in backgrounds instead of single one? > Documents with lot of figures take a long time to load fully and most > of nowadays machines have multiples cores, to do that job in parallel. > > Pavel Yes, this should be really useful. I'll check it. BTW did get to it? Pavel Pavel, I didn't forget about this and have some progress in this direction. It is in my lyx-todo list just after completing with 2 branches in features repository. Since it was announced that only bug-fixing patches are allowed in master branch, I paused all development/refactoring/cleanup activities till the release of version 2.4.0. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Set correct Windows console code page since all LyX output is, in UTF-8
Looks reasonable to me. Pavel Thanks, committed. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Set correct Windows console code page since all LyX output is, in UTF-8
Now all LyX console output other than ASCII is broken since LyX outputs
UTF-8, but the default code page in Windows console is not UTF-8 and
depends on the locale
(https://docs.microsoft.com/en-us/windows/console/console-code-pages).
Attached patch fixes this issue. Is it OK to commit?
Yuriy
From 56cc76bff7e91ab4dedda0281ae9c4926121b176 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 11 Mar 2021 16:19:44 +0200
Subject: [PATCH] Set correct Windows console code page since all LyX output is
in UTF-8
---
src/main.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/main.cpp b/src/main.cpp
index 94b1ccd646..65a9f4d8d7 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -40,6 +40,7 @@ int main(int argc, char * argv[])
freopen("CONOUT$", "w", stdout);
freopen("CONOUT$", "w", stderr);
}
+ SetConsoleOutputCP(CP_UTF8);
#endif
// To avoid ordering of global object problems with some
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Some fixes
Both look good. Jürgen Thanks for reviewing, committed. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Some fixes
Hello,
Please review two attached patches:
1. Now setting of math matrix size by dragging mouse is imprecise due to
Qt limit on min cell size. The patch fixes this.
2. Now Beamer columns have fixed margin size determined by
untranslatable English string. The patch changes it to dynamic.
Yuriy
From bf9914554df866ddc7740f36f98d8a6d8ac5334d Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 18 Feb 2021 15:36:24 +0200
Subject: [PATCH 1/2] Fix setting of math matrix size with mouse
---
src/frontends/qt/EmptyTable.cpp | 16
src/frontends/qt/EmptyTable.h | 4
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/frontends/qt/EmptyTable.cpp b/src/frontends/qt/EmptyTable.cpp
index bc2963ba32..80cbe88aec 100644
--- a/src/frontends/qt/EmptyTable.cpp
+++ b/src/frontends/qt/EmptyTable.cpp
@@ -22,10 +22,6 @@
* A simple widget for a quick "preview" in TabularCreateDialog
*/
-unsigned int const cellheight = 20;
-unsigned int const cellwidth = 30;
-
-
EmptyTable::EmptyTable(QWidget * parent, int rows, int columns)
: QTableWidget(rows, columns, parent)
{
@@ -34,7 +30,9 @@ EmptyTable::EmptyTable(QWidget * parent, int rows, int
columns)
setVerticalScrollBarPolicy(Qt::ScrollBarAsNeeded);
viewport()->resize(cellheight * rows, cellwidth * columns);
setSelectionMode(QAbstractItemView::NoSelection);
+ setFocusPolicy(Qt::NoFocus);
setEditTriggers(QAbstractItemView::NoEditTriggers);
+ adjustMinCellSize();
}
@@ -43,6 +41,16 @@ QSize EmptyTable::sizeHint() const
return QSize(cellwidth * (2 + columnCount()), cellheight * (2 +
rowCount()));
}
+
+void EmptyTable::adjustMinCellSize()
+{
+ setRowHeight(0, cellheight);
+ cellheight = rowHeight(0);
+ setColumnWidth(0, cellwidth);
+ cellwidth = columnWidth(0);
+}
+
+
void EmptyTable::resetCellSize()
{
for(int i = 0; i < rowCount(); ++i)
diff --git a/src/frontends/qt/EmptyTable.h b/src/frontends/qt/EmptyTable.h
index 99265266d2..9285db5ceb 100644
--- a/src/frontends/qt/EmptyTable.h
+++ b/src/frontends/qt/EmptyTable.h
@@ -49,6 +49,10 @@ protected:
virtual void resetCellSize();
private:
+ void adjustMinCellSize();
+
+ int cellheight = 20;
+ int cellwidth = 30;
};
--
2.28.0.windows.1
From ffaab2a0b889bbc0967346fda5df5090beb1597d Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 18 Feb 2021 15:38:13 +0200
Subject: [PATCH 2/2] Fix margins for Beamer columns
---
lib/layouts/beamer.layout | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/lib/layouts/beamer.layout b/lib/layouts/beamer.layout
index 61d8823770..a26c409783 100644
--- a/lib/layouts/beamer.layout
+++ b/lib/layouts/beamer.layout
@@ -666,12 +666,12 @@ End
#
-# COLUMS
+# COLUMNS
#
Style Column
Category Columns
- Margin Static
+ Margin Dynamic
LatexTypeCommand
LatexNamecolumn
ParSkip 0.5
@@ -689,7 +689,6 @@ Style Column
LabelString"Options"
Tooltip"Column options (see beamer manual)"
EndArgument
- LeftMargin "Start column (increase depth!), width:xx"
LabelFont
Family Roman
Color latex
@@ -699,16 +698,15 @@ End
Style Columns
Category Columns
KeepEmpty1
- Margin Static
+ Margin First_Dynamic
LatexTypeEnvironment
- NextNoIndent 0
+ NextNoIndent 1
ParIndentMM
AlignLeft
LabelTypeStatic
LabelSep xx
LatexNamecolumns
LabelString "Columns"
- LeftMargin "Columnsxx"
Argument 1
LabelString"Column Placement Options"
Tooltip"Column placement options (t, T, c, b)"
@@ -732,7 +730,6 @@ Style ColumnsCenterAligned
CopyStyleColumns
LatexParam [c]
LabelString "Columns (center aligned)"
- LeftMargin "Columns (center aligned)xx"
ResetArgs1
End
@@ -740,7 +737,6 @@ Style ColumnsTopAligned
CopyStyleColumns
LatexParam [t]
LabelString "Columns (top aligned)"
- LeftMargin "Columns (top aligned)xx"
ResetArgs1
End
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Dear all I have a patch ready that moves the simple search dialog to the bottom dock widget (see attached screenshot). This solves some long standing UI issues: * https://www.lyx.org/trac/ticket/2625 * https://www.lyx.org/trac/ticket/8054 Most importantly, search is more convenient when using the keyboard (Ctrl-F toggles the search pane on and off, F3/Ctrl-F3 or Cmd-G/Shift- Cmd-G, Return/Shift-Return and the respective accelerators search backwards and forward, backwards search/replace does not need a checkbox to be enabled), and there is no dialog getting in the way of search results. To me, the UX seems significantly improved. The space taken is absolutely acceptable (note that the screenshot shows a minimized main window), but if wanted, I can also add a button that hides the replace and options widgets. Is this something we want in LyX 2.4? Jürgen I like it. +1 for 2.4 Kornel Thanks for working on this, Jürgen. I'd also like to have this in LyX 2.4. Current search dialog too frequently overlaps found text (only moving it outside LyX window helps). The only minor issue for me is the button captions that differ only by icons. Is it possible to use something like "Find Previous" "Find Next" (or even just "Previous" "Next")? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
Compiles fine. Test is very fast (no options used) Is that the expected output? ... [doctest] doctest version is "2.4.5" [doctest] run with "--help" for options === [doctest] test cases: 14 | 14 passed | 0 failed | 0 skipped [doctest] assertions: 108 | 108 passed | 0 failed | [doctest] Status: SUCCESS! Kornel Thanks for a quick try, Kornel. Yes, this is an expected output. It is pretty fast now and I hope it will remain fast with more tests. Now most time is spent by LyX startup (loading layouts etc). I presume you'll be interested in trying it to test Advanced Search. The src/test/issues/12069.cpp can be used as a sample. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
I'm all for focusing on 2.4.0 release. So I'll not push yet my commits into newly created branch features/unit-test-adoption. After some time-out I've pushed my work on unit testing into unit-test-adoption branch in features repository. So if you have some free time and are interested, please try it. Here are some notes: * Now it supports CMake only * I've added a short section documenting this in Development manual * There are several changes that makes testing easier/possible: - (Inset...) made several virtual methods public (as in base class Inset) that wrongly were private in several derived classes - (lyxfind) made public findOne function to get rid of messagebox displaying - (ExternalTransforms) throw an exception instead of direct output to lyxerr stream to get clean console output when running tests Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Insert menu
Also I think marginal notes are too different sorts of notes than the ones in the Notes submenu. Footnotes and marginal notes are part of the document structure, the other notes are more editorial devices (the rather esoteric "gray text", whose purpose I never fully grasped, note might be a hybrid). Here again, the English word form (which does not easily translate to other languages) might be misleading. The (co-)incidence that all these are termed "notes" in English does not mean they have much in common. Jürgen Exactly the existence of this esoteric "gray text" caused me to think about the merge. It is now widely used in e.g. EmbeddedObjects manual as a part of the document structure. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Insert menu
I would think Marginal Notes could certainly go with notes. But footnotes are so common, at least in academic writing, that I'd be reluctant to move them another keystroke away. Riki But frequent usage of menu for this is not very effective. There is a convenient toolbar button for this. Also defining some shortcut for footnote (say Ctrl-Alt-F) will be good too. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Insert menu
I don't think this is a very good category name. Also I think that
these are all sorts of "lists" that can be grouped together. In German,
we have the general term "Verzeichnisse" which perfectly fits them all
(TOC is "Inhaltsverzeichnis", Bibliography "Literaturverzeichnis", List
of Figure "Abbildungsverzeichnis", Index "Stichwortverzeichnis"). It is
too bad that English (apparently due to some historical contingencies)
distinguishes "lists", "tables" etc. So we need this rather crude entry
for English.
However, I do not think that we should structure the menu based on
English semantics.
Jürgen
I agree that current state of menu is better where these items are
grouped. Also TOC is very common at the end of the books in Russian and
nomenclatures -- at the front.
But I agree with another Andrew's proposition:
I realise this adds another item to a long Insert menu, but an overall shrinkage by one follows if
"Footnote" and "Marginal Note" are included under "Note".
The Insert menu is really long and already caused some inconveniences
for me on smaller screens. Also these items ("Footnote" and "Marginal
Note") can be separated by line from the rest in the Note submenu.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Patches to review
Thanks for all for reviewing the patches!
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's
not the case [1, 2].
Sorry that I don't know enough to look at the others.
Scott
Yes, it is Qt4.8-compatible. I have its docs installed and check
compatibility before any usage of newer names.
Concerning patch 1 and 5: what guideline do you use for using vector vs list.
The patches look good, I am just wondering.
Concerning patch 4: what does the replacement of 0 or nullptr by {} bring?
JMarc
You've meant patches 2 and 5? In patch 2, QList is a dynamic array
similar to std::vector, so just use std library instead of Qt where it
is not required. In patch 5, the container usage is just fits linked
list the best -- insertions at the front and deleting in the middle are
ineffective in vectors.
As for the patch 4 there are warnings about this from Qt.
Here I experimented with automatic LyX build using GitHub Actions:
https://github.com/magistere/lyx/actions
Logs with warnings can be seen when you log in to GitHub.
Also there are several code scanning tools, that give some warnings.
Maybe some will be useful to fix. They are available here (again only
after logging in): https://github.com/magistere/lyx/security/code-scanning
2,3 is fine. 5 is fine unless we use direct [] access somewhere.
I know Riki did not announce it officially yet, but we should start looking at
fixing
bugs which hinder us from 2.4 release rather than refactoring the codebase. I
know, boring...
Pavel
As I've checked, there is no random access for lastfiles container.
Not part of your changes but the weird 3 line comment above could be just
single line
Pavel
Strict 80 chars per line setting in someone's editor. As I understand
there is no such requirement, right? We can mention this in
Development.lyx manual.
I think I did send an email to that effect. In any event, my understanding is
that Yuriy intends to commit these things to a feature branch for now. We don't
want to risk another weird surprise like with the move constructor.
Riki
Probably I violated this. I'm not sure if it is worth to create another
branch for these patches. So let's just postpone them for some time.
I'll commit the documentation patch only since it would be safe.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
ru/UserGuide ctests failing
There are several ru/UserGuide ctests failing on current master, including the default output (pdflatex). Scott That is after my latest patch to it? It was an update in contents of the document, no changes in settings. What are the errors? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Patches to review
Please review my recent patches for LyX.
Yuriy
From 9c9fd209149b05d6ec879d1792b9628734ce3ed5 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 10 Jan 2021 13:27:40 +0200
Subject: [PATCH 1/5] Update Development.lyx
---
lib/doc/Development.lyx | 99 +++--
1 file changed, 65 insertions(+), 34 deletions(-)
diff --git a/lib/doc/Development.lyx b/lib/doc/Development.lyx
index 5a4c3864d7..46f253ff11 100644
--- a/lib/doc/Development.lyx
+++ b/lib/doc/Development.lyx
@@ -1,5 +1,5 @@
#LyX 2.4 created this file. For more info see https://www.lyx.org/
-\lyxformat 600
+\lyxformat 601
\begin_document
\begin_header
\save_transient_properties true
@@ -3616,7 +3616,7 @@ Wontfix
\end_layout
\begin_layout Paragraph
-suspended tests
+Suspended tests
\end_layout
\begin_layout Standard
@@ -5178,7 +5178,7 @@ PDF (pdflatex)
\begin_layout Enumerate
All fixes (typos, compilation fixes, updates info etc.) go at first into
- the current GIT branch because the user should benefit from all fixes with
+ the current Git branch because the user should benefit from all fixes with
every minor release.
Feel free to commit directly to branch as long as you follow rule
\begin_inset space ~
@@ -5213,12 +5213,10 @@ The main documentation consists of these files:
\end_layout
\begin_layout Description
-Welcome.lyx it is the first file you see after an installation.
+Welcome.lyx It is the first file you see after an installation.
We assume that a new user sees this.
It is therefore designed to be as simple as possible.
Therefore please don't add any new formatting, only fix typos etc.
- Welcome.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe Stöhr.
\end_layout
\begin_layout Description
@@ -5229,60 +5227,47 @@ Intro.lyx This is the manual new users will read to
learn \SpecialChar LyX
Since new users will first learn about the formatting possibilities of
\SpecialChar LyX
please keep this file that simple.
- Intro.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe Stöhr.
\end_layout
\begin_layout Description
-Tutorial.lyx our tutorial.
+Tutorial.lyx Our tutorial.
It must be always up to date.
Normally there is nothing to add since we don't want to overwhelm new users
with too much details.
- The will learn these details while using \SpecialChar LyX
+ They will learn these details while using \SpecialChar LyX
and we have special manuals.
- Tutorial.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe Stöhr.
\end_layout
\begin_layout Description
-UserGuide.lyx our main user guide.
+UserGuide.lyx Our main user guide.
It covers a mixture of basic and detailed information.
Some information is also in the Math and EmbeddedObjects manual so that
the UserGuide refers to these files.
- UserGuide.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe Stöhr.
\end_layout
\begin_layout Description
-EmbeddedObjects.lyx a special manual to explain things like tables floats
+EmbeddedObjects.lyx A special manual to explain things like tables floats
boxes etc.
in all detail.
- EmbeddedObjects.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe
- Stöhr.
\end_layout
\begin_layout Description
-Math.lyx a special manual to explain everything regarding math in all detail.
- Math.lyx is up to date for \SpecialChar LyX
- 2.1.x, currently maintained by Uwe Stöhr.
+Math.lyx A special manual to explain everything regarding math in all detail.
\end_layout
\begin_layout Description
-Additional.lyx this manual covers information that would be too much detail
+Additional.lyx This manual covers information that would be too much detail
for the UserGuide or would make the UserGuide uncompilable or only compilable
when installing a lot of special \SpecialChar LaTeX
--packages.
+ packages.
What should be in the UserGuide or better in Additional is a matter of
taste.
- it is up to you to decide that.
- Additional.lyx is not completely up to date for \SpecialChar LyX
- 2.1.x.
- Only chapter
+ It is up to you to decide that.
+ Additional.lyx is not completely up to date (only chapter
\begin_inset space ~
\end_inset
-8 is up to date and currently maintained by Uwe Stöhr.
+8 is up to date).
It certainly needs a rewrite and update.
For example many info in chapter
\begin_inset space ~
@@ -5293,7 +5278,7 @@ Additional.lyx this manual covers information that would
be too much detail
\end_layout
\begin_layout Description
-Customization.lyx this manual covers information how to customize \SpecialChar
LyX
+Customization.lyx This manual covers information how to customize \SpecialChar
LyX
for certain
output formats, operating systems, languages etc.
It is currently completely out of date and needs a major rewrite and update.
@@ -5861,7 +5846,12 @@ switch (f) {
\begin_layout Plain Layout
-case FOO_BAR1: .
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
I've tried to reproduce on Linux with Clang and libc++ but cannot. However, one thing that I do not understand is that in the output from ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this expected? Scott linux-vdso.so.1 (0x7ffd059e5000) libmythes-1.2.so.0 => /lib/x86_64-linux-gnu/libmythes-1.2.so.0 (0x7f990dad1000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f990d993000) libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x7f990d98c000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7f990d962000) libenchant-2.so.2 => /lib/x86_64-linux-gnu/libenchant-2.so.2 (0x7f990d954000) libmagic.so.1 => /lib/x86_64-linux-gnu/libmagic.so.1 (0x7f990d92c000) libQt5Concurrent.so.5 => /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 (0x7f990d921000) libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 (0x7f990d8c5000) libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x7f990d229000) libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x7f990cb71000) libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x7f990c633000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f990c616000) libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x7f990c54e000) libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x7f990c516000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f990c3c7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f990c3ac000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f990c1c2000) /lib64/ld-linux-x86-64.so.2 (0x7f990dafb000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f990bfe1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f990bfd9000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x7f990bfd3000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f990bfcb000) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7f990bfc5000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f990be93000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f990be6a000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f990be55000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f990be33000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f990bdab000) libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7f990bd72000) libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x7f990bc91000) libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x7f990bc7d000) libdouble-conversion.so.3 => /lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7f990bc65000) libicui18n.so.67 => /lib/x86_64-linux-gnu/libicui18n.so.67 (0x7f990b953000) libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 (0x7f990b767000) libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 (0x7f990b6e4000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f990b614000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f990b607000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x7f990b5fd000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f990b5e3000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f990b57) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x7f990b4b8000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x7f990b482000) libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x7f990b3bf000) libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x7f990b392000) libicudata.so.67 => /lib/x86_64-linux-gnu/libicudata.so.67 (0x7f9909879000) libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x7f990986b000) libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x7f9909846000) Yes, this is expected, since system libQt5*.so are dependent on libstdc++ (assuming you haven't rebuild Qt with libc++). ldd displays all required libraries, not only the ones that directly used by the application. So, seems that the issue with move constuctor patch is shown up only on macOS. Now I'm not sure how to debug it, since I have no Mac. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
The next step from my side should be clang installation and debugging this patch there. But it can happen not very soon. It happened sooner than I expected. I've got Clang 11 from winlibs.com (it uses libstdc++, unfortunately libc++ is not available here). It compiles LyX on Windows without any problems and the opening of the recent files doesn't crash. So the problem is definitely in libc++, as Jean-Marc suspected from the start. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
I'm hoping that people will focus their energies mostly on bug-fixing for the 2.4.0 release. But I understand that that isn't as fun as doing new things. Also, I usually think it's best to get agreement on the framework before launching into a lot of work. But, in this case, I think maybe many of us need to see what this might look like, so starting to develop the framework in a feature branch (even if it happened after 2.4.0) is the way to go. I'm all for focusing on 2.4.0 release. So I'll not push yet my commits into newly created branch features/unit-test-adoption. Are there strong arguments in favor of other frameworks? Expanding the tests in support/, and integrating the existing ones into whatever framework you have in mind, would be a good start, I think. Riki Yes, as you can see in the patch from the first thread message, I started exactly from this. Of course testing GUI code will be harder, but we can begin with testing the core code. Also I want to propose an easy way to gradually increase test coverage -- after fixing the bug to add a test so this bug will immediately show up if it reappear due to future changes. Recent bug #12069 will be a good candidate for this. I'll write corresponding test for it. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Thanks Stephan. It crashes on the call to move(?) assignment operator, but it is still not clear looking on these sources. I haven't tried Valgrind yet. To trigger the crash I picked the second file out of the five files in the lastfiles vector. (But this happens with the first and with the last entry the same way.) This operation effectively should move the 2nd entry to the 1st position. The implemented logic in LastFilesSection::add removes the 2nd entry because of the match and inserts this FileName instance at position 1. IMO the assignee (the new 1st slot of the lastfiles vector) hasn’t allocated the memory for private member d when the assignment operator is called - instead it is zero filled at that point. I’m not so familiar with C++ internals. Perhaps the constructor wasn’t called or a wrong one or the move assignment constructor should care for it. Perhaps it is the implementation of the vector? Stephan I've had a chance to use Valgrind. It runs without any issues there. The next step from my side should be clang installation and debugging this patch there. But it can happen not very soon. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX features/InsetParams-refactoring] Refactor decodeInsetParam
These have mostly been posted before, yes? Riki Yes, only the latest three are new. Please review them when you'll have time. I'm finished with it for now. Here is the thread in which I've sent previous patches: https://marc.info/?t=16071855355&r=1&w=2 Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[Windows] Remove the default binding between buffer-zoom and Alt+0
However, by default, in LyX, this has a very problematic side-effect: Alt+0 resets the zoom level to zero. Personally, I know how to configure this shortcut, but newcomers may be left puzzled (and leave completely). Moreover, it's more common to use Ctrl+0 to reset the zoom level, at least on Windows: most Web browsers do it (at least Firefox, Chrome, and IE), all Microsoft Office programs. It does not work for LibreOffice or Notepad++. I would propose to change the default binding to Ctrl+0, as it's more common (although not ubiquitous), and this would fix the problem of changing zoom when you try to insert a character. What do you think of this? There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent these should also use Ctrl. But Ctrl+"-" is already bound to Hyphenation Point insert. Is it OK to rebind it to Alt+"-"? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Creating a branch in the features repository
But there were some messages about big file. Is it normal? The email is too big. Probably because you are pushing a billion commits. Definitely, there were several thousand commits. So that was just email for mailing list. Thanks for the explanation. I think it is worth to sync master branch in features repository (last updated in 2015) with master in main repository. This will allow not to push all commits from 2015 to 2021 for every new feature branch. Is it OK if I'll do this? Yes, I think that is fine. Probably you get the same error again, but it's harmless. Riki So, I updated the master branch there and Git become more responsive. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Creating a branch in the features repository
Recently I've created a new branch in the features repository as described here: https://wiki.lyx.org/Devel/LyXGit#toc3 But there were some messages about big file. Is it normal? Here is the Git output: - C:\Projects\LyXGit\lyx>git push features InsetParams-refactoring:InsetParams-refactoring Enter passphrase for key '/c/Users/Yuriy/.ssh/id_rsa': Enumerating objects: 6533, done. Counting objects: 100% (6533/6533), done. Delta compression using up to 4 threads Compressing objects: 100% (2758/2758), done. Writing objects: 100% (5304/5304), 8.09 MiB | 2.38 MiB/s, done. Total 5304 (delta 4473), reused 3036 (delta 2489), pack-reused 0 remote: postdrop: warning: uid=1005: File too large remote: sendmail: fatal: yuriy.ska...@gmail.com(1005): message file too big To git.lyx.org:features.git * [new branch]InsetParams-refactoring -> InsetParams-refactoring - I think it is worth to sync master branch in features repository (last updated in 2015) with master in main repository. This will allow not to push all commits from 2015 to 2021 for every new feature branch. Is it OK if I'll do this? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
OK, now will you commit the replacements? Kornel Please commit them. I don't have patch and only figured out why that call is considered ambiguous by Clang. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
Thanks for continuing this conversation, Yuriy. Scott, thanks for such detailed reply. I'm strongly in favor of a unit testing framework. That said, I just don't think most LyX developers are. I don't know if it's because writing tests is not fun or if the belief is that the time spent to write tests would be better spent working directly on bugs/features. Even if it's the "fun" argument, I think that's understandable. People contribute to LyX in their own free time. I often choose what to work on based on what I find fun. In any case, I should also say that I don't have experience with unit tests so I cannot make any substantive claim based on my own experience. I also believe that unit tests would be very useful. They can provide some kind of safety net to save already working features. I don't know if it's worth going forward without the support of most developers. I'm not sure at all in what I'm about to say (given my lack of experience), but I feel like writing unit tests is the sort of thing where each developer kind of thinks along the lines of "OK I don't like writing tests, no one *enjoys* writing tests... but if you do it I'll do it." And if every developer takes that approach, and we hold each other accountable, over time we get more coverage and the code base becomes more robust. Indeed I see a lot of regressions on master that I wonder "hmmm I bet we could have had a test that would have caught that." Most of the time these regressions are short-lived (but even these are annoying and time-consuming), but some of them go unnoticed for a while. If just a few developers write tests, then I think there might be more frustration than benefit. I will document below the situation with ctests. I think that ctests are very different (especially the first point below :)) from the potential unit test framework, but perhaps the description will be useful to you in some way. I see 6 reasons why developers aren't interested in the ctests: (1) the ctests are not unit tests; (2) to understand the full suite of our ctests is complex and non-standard and would take developers a lot of time. We tried to document things in Development.lyx, but it is still confusing (I'm willing to clear up any confusion in the document if anyone has a specific question). At least for commits that change LaTeX output, it would be really nice if the developer ran the ctests to see which fail that weren't failing before. LaTeX is so complex and there are so many interactions and things that cause unexpected failures in compilation that the ctests catch a lot of regressions. However, (3) running all of the ctests takes a long time and perhaps because of power bills people do not want to leave their computer running the tests overnight and push their commit in the morning. Kornel and I even offer to take care of running the ctests on a patch/branch before someone commits it to master, but I think developers just (4) don't want to wait or have any extra step in their commit chain. And I think that most developers (5) are fine with the idea of "eh let's just fix it on master, master is not meant to be stable anyway." Finally, (6) the ctests are tied to CMake and a lot of developers prefer autotools. Yes, current ctests that used mostly for testing export outputs as are very different. I think the main issue that they are not popular is the long time to run them. I'm sure if ctests could complete in several seconds/minutes they would be run much frequently. But I presume there are not much possibilities to accelerate them, running LaTeX is time consuming task. So we should learn from ctests adoption and try to do better for unit tests: 1. It should be simple to write and fast to execute many (hundreds) tests. So no more separate executables for every testcase, shell scripts for checking the outputs, data files with correct results (as in current LyX unit tests in `tests` directories). I think the best solution will be integrating tests into main LyX executable in debug mode (or even in release mode, depending on build system option) and providing --test command-line option to run them. The test runner of the framework is flexible and allows to choose what tests to run, so more heavy tests can be skipped if necessary. All tests will be located in src/test directory and linked into executable only in debug mode. Doctest framework even suggests to write unit tests directly in the same file as tested function/class. But I think this approach is too radical for the LyX project. 2. We should try to get along without mocks/dummy_functions since LyX doesn't use potentially time-consuming external dependencies like databases and networking. But if tests are part of the full LyX executable, it simplifies this task. (This approach is somewhat different than my first try in initial message in this thread. But the updated patch is largely ready.) I hope that deve
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Maybe '-std=c++17'? AFAIR Scott successfully compiled LyX with -std=c++20 on Clang. Other compiler options also seem usual. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
I used the debugger to bring some light into it. Thanks Stephan. It crashes on the call to move(?) assignment operator, but it is still not clear looking on these sources. I haven't tried Valgrind yet. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Yes, it helps. Now the next are /usr2/src/lyx/lyx-git/src/graphics/GraphicsCacheItem.cpp:445 /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:602 /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:687 /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:772 /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:860 /usr2/src/lyx/lyx-git/src/Buffer.cpp:1474 /usr2/src/lyx/lyx-git/src/BufferList.cpp:131 /usr2/src/lyx/lyx-git/src/TocBackend.cpp:148 Changing all of them now compiles. Thanks. Kornel Great. So Clang is more strict than GCC. But why Stephan and Scott don't have these errors with it? Do you have some additional compiler flags active? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Should it work w/o -std=c++17? What do expect to happen with different
compiler switches for build of Qt-libs and LyX?
On GCC it works now with all standards: from C++11 to C++20.
The show stopper with -mmacosx-version-min=10.10 is:
/Users/stephan/git/lyx/src/insets/ExternalTransforms.cpp:334:20: error:
'any_castlyx::external::TransformCommand, std::__1::default_delete lyx::external::TransformCommand> > (lyx::external::RotationData)> >' is
unavailable: introduced in macOS 10.14
Factory factory = any_cast(any_factory);
Now for C++17 we are using `any` and `any_cast` implementations from
standard library (instead of boost's for earlier standards). Seems like
it is somehow broken on macOS.
Try to leave only the boost conditional compilation branch in support/any.h:
#include
namespace lyx {
using boost::any;
using boost::any_cast;
}
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
I cannot even compile everything under clang8 /usr2/src/lyx/lyx-git/src/support/FileMonitor.cpp:62:9: error: call to 'make_unique' is ambiguous return make_unique(instance().getGuard(filename)); ^~~~ /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unique_ptr.h:834:5: note: candidate function [with _Tp = lyx::support::FileMonitor, _Args = >] make_unique(_Args&&... __args) Kornel Does replacing make_unique with lyx::make_unique help? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
I am reluctant ... have you seen, how many tests (in cmake) there already are? Here it gives $ ctest -N | wc 7605 22812 504591 OTOH, more tests cannot hurt. Kornel Yes, I've seen (and really appreciate) that there are many ctests. As I understand these are export tests that check if output files are correct (is it so?). Using testing framework is on a different level of testing, it will allow to test separate functions and classes, and also their interactions. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Sorry, I’ve reverted the change for now locally. I can answer your questions later… Perhaps the compiler flags of the autotools build are of interest (but cmake build crashes either): Configuration Host type: x86_64-apple-darwin18.7.0 Special build flags: build=release warnings callback-printing use-hunspell use-aspell Bundled libraries:nod boost mythes C++ Compiler:c++ -stdlib=libc++ (11.0.0) C++ Compiler flags: -Wall -Wextra -fPIC -Os -std=c++17 -Wno-deprecated-register C++ Compiler user flags: -I/Users/Shared/LyX/utilities/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -arch x86_64 -mmacosx-version-min=10.10 -std=c++17 -std=c++11 Linker flags: -rdynamic Linker user flags:-L/Users/Shared/LyX/utilities/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -arch x86_64 -mmacosx-version-min=10.10 Qt Frontend: Qt version: 5.12.9 Packaging: macosx Are all these library and compiler standard choice switches compatible and correct? Stephan Thanks for testing Stephan and Scott. So seems like it is macos-only issue. I see nothing suspicious in your compiler flags (are you manually override default C++17 to C++11?). The patch is already reverted in master branch. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Regular crash in modifying regex
Does not crash for me. Can you produce a backtrace? Jürgen Also cannot reproduce on Windows. It is strange that constification commit breaks the search. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Use C++ testing framework
On 16.12.2020 22:14, Yuriy Skalko wrote: There were already several discussions here in 2013, 2015 and even in 1999 about using some unit testing framework, but without any tangible result. I think it is now time to change this :) There are several widely used frameworks, I've chosen "doctest" (https://github.com/onqtam/doctest/). It is not the most popular, but is the fasest and has small size -- it consists of only one file. Also it is very convenient to use (https://github.com/onqtam/doctest/blob/master/doc/markdown/tutorial.md). Now LyX has some simple hand-made unit testing in `tests` directories that is used to test a few base classes/functions. I've converted some of these tests to the new framework. I only updated/added CMake files and these surely will require further improvements. So, what is your opinion about this change? Comments are very appreciated. Yuriy Ping... -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Add move constructor and move assignment operator for FileName class
Frankly, I am not at ease at all with the way things get updated. I do not understand the Qt mechanisms well enough. If you feel like trying to understand it, please do. Be warn though that we are in a working but fragile situation now, changes will lead to a rough ride but it is probably worth the cost. JMarc Yes, many parts in LyX code are very coupled and some change can cause unexpected consequences in seemingly unrelated places (I've already encountered this for much smaller changes). So without solid knowledge of LyX code it will be hard not to broke anything. Introducing common testing framework (for both unit and integration tests) should help with confidence that things still work after introducing the change (but it is not so simple for gui stuff). I think this should be the first step before doing such significant modifications. Recently I've sent a message on this subject in this mailing list but have not received any feedback. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
Hi Yuriy, I’m seeing a crash after this commit when using File->Open recent. I’m having 5 files in list and the first entry has nullptr as private data. Hi Stephan, Sorry for late answer. Does it crash always on choosing the first file in Recent list? I cannot reproduce this on Windows and Linux (using GCC in both cases) and suspect it is Clang-only issue. As I understand Scott used Clang on Linux. Is this crash reproducible there? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: What Localized Manuals Are Maintained?
> Before I send a note asking for help with the copy-paste stuff, what localized manuals are currently maintained? I.e., for which languages do we need to copy over the new and changed material? As I said yesterday, manuals other than Intro and Tutorial are localized in French, German, Japanese ans Spanish. There are also newly introduced manuals in Russian. But they are already prepared for LyX 2.4, so no need to copy over any material. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Add move constructor and move assignment operator for FileName class
Also I noticed that these files are accessed on every keypress (even on navigating document with arrows): lib/images/undo.svgz lib/images/textstyle-apply.svgz lib/images/paste.svgz Is it *really* necessary? It would be because of getStatus, I suspect, though I'm not sure why the files would be accessed. Maybe because the toolbar items are being enabled/disabled? But surely that only need happen if there's been a change. Riki Only these files? JMarc Yes, only these 3. Seems like this is caused by `getIcon` calls in DynamicMenuButton::updateTriggered (called on every toolbar update, that happens on every key press). And `getIcon` doesn't just return icon from some cache, but directly checks the file on disk. I'm not sure how to fix it the right way. Now almost full update of GUI state update (dialogs, toolbars, statusbar) is done in GuiView::restartCaret that is called in several places in GuiApplication::processKeySym. It will be great to implement more fine-grained control of the GUI update. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Add move constructor and move assignment operator for FileName class
I don't know enough about this stuff to say much. I think this would be worth doing for 2.4.0, as it will probably provide for some speed as well. Riki Committed at 854c9de. Also I noticed that these files are accessed on every keypress (even on navigating document with arrows): lib/images/undo.svgz lib/images/textstyle-apply.svgz lib/images/paste.svgz Is it *really* necessary? Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] Add move constructor and move assignment operator for FileName class
This should reduce memory allocations for this heavily used class.
Yuriy
From 15c952108bd6e79a712f159326804a145186b50b Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 7 Jan 2021 02:27:31 +0200
Subject: [PATCH] Add move constructor and move assignment operator for
FileName class
---
src/support/FileName.cpp | 16
src/support/FileName.h | 14 ++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index 5295741e1a..b9a1d4315b 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -158,6 +158,13 @@ FileName::FileName(FileName const & rhs) : d(new Private)
}
+FileName::FileName(FileName && rhs) noexcept
+ : d(rhs.d)
+{
+ rhs.d = nullptr;
+}
+
+
FileName::FileName(FileName const & rhs, string const & suffix) : d(new
Private)
{
set(rhs, suffix);
@@ -174,6 +181,15 @@ FileName & FileName::operator=(FileName const & rhs)
}
+FileName & FileName::operator=(FileName && rhs) noexcept
+{
+ auto temp = rhs.d;
+ rhs.d = d;
+ d = temp;
+ return *this;
+}
+
+
bool FileName::empty() const
{
return d->name.empty();
diff --git a/src/support/FileName.h b/src/support/FileName.h
index 1cf1e730f4..2bc2e48b80 100644
--- a/src/support/FileName.h
+++ b/src/support/FileName.h
@@ -42,15 +42,21 @@ public:
*/
explicit FileName(std::string const & abs_filename);
- /// copy constructor.
+ /// copy constructor
FileName(FileName const &);
- /// constructor with base name and suffix.
+ /// move constructor
+ FileName(FileName &&) noexcept;
+
+ /// constructor with base name and suffix
FileName(FileName const & fn, std::string const & suffix);
- ///
+ /// copy assign
FileName & operator=(FileName const &);
+ /// move assign
+ FileName & operator=(FileName &&) noexcept;
+
virtual ~FileName();
/** Set a new filename.
* \param filename the file in question. Must have an absolute path.
@@ -219,7 +225,7 @@ private:
bool copyTo(FileName const &, bool, FileNameSet &) const;
///
struct Private;
- Private * const d;
+ Private * d;
};
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problem with standard regex
> BTW, I tested the regexes with Russian documents, and found an error in > Additional.lyx > Correction attached. Really, that was missed out. Please commit it. Done at c6bc5f0c Thanks. I've tested the regexes (with and without format). Now there are no problems with Cyrillic in any practical regexes I can think of. Thanks for advsearch that is really usable now, Kornel! Tried some exotic ways? 1.) Search for 3 or more consecutive identical chars '(\S)\1\1+' 2.) Repeated words '\b(\w+)\s+\1\b' # You will find 'действительно действительно', 'после после' in Additional.lyx 3.) Different languages (e.g.Latin) (Wrap the whole expression into Latin env '.+' etc Kornel Of course I've not tried such regexps. These are interesting and really useful. I've done search for repeated words in LyX manuals and fixed a few. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problem with standard regex
Thanks. I am not so sure that 'from_ascii()' is the better choice comparing to 'from_utf8()' though. Maybe it will be better, but I cannot remember seeing exceptions with `what`-messages not in plain English. Feel free to update. BTW, I tested the regexes with Russian documents, and found an error in Additional.lyx Correction attached. Really, that was missed out. Please commit it. Is the regex handling (with enabled format) now to your liking? Kornel I've tested the regexes (with and without format). Now there are no problems with Cyrillic in any practical regexes I can think of. Thanks for advsearch that is really usable now, Kornel! Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: XML stream writer library
TinyXML2 (https://github.com/leethomason/tinyxml2), pugixml ( https://github.com/zeux/pugixml), and Xerces-C++ ( https://xerces.apache.org/xerces-c/) are only DOM-based. There are quite a few C libraries, like libxml2, that can be SAX-like, but C libraries are horrible to use (http://www.xmlsoft.org/examples/testWriter.c). There are several C++ wrappers for libxml2 on GitHub. Maybe they can be useful: https://github.com/libxmlplusplus/libxmlplusplus https://github.com/rioki/libxmlmm Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problem with standard regex
Thanks, you are right. But since the exception may not be only from regex, 'ex.what()' alone feels better. Please commit. Kornel Committed at e8099942c7. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problem with standard regex
Further investigating shows the error in my own code (out of range access).
The following exception was catched in the try {} section in findAdv(), so
the only
message was: "Invalid regular expression!". This was misleading.
Indeed that's not very helpful. Ideally it would say *why* it is not valid.
Maybe append additional exception message to that generic "Invalid..."
message as in attached patch?
Yuriy
diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
index c728af1cef..9bd77e739f 100644
--- a/src/lyxfind.cpp
+++ b/src/lyxfind.cpp
@@ -4115,9 +4115,9 @@ bool findAdv(BufferView * bv, FindAndReplaceOptions const
& opt)
match_len = findForwardAdv(cur, matchAdv);
else
match_len = findBackwardsAdv(cur, matchAdv);
- } catch (...) {
+ } catch (exception & ex) {
// This may only be raised by lyx::regex()
- bv->message(_("Invalid regular expression!"));
+ bv->message(_("Invalid regular expression!") + ' ' + ex.what());
return false;
}
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compilation error with MSVC 19
> I think the right way will be using only standard-compliant
> "__cplusplus" in sources and adding the option "/Zc:__cplusplus" for
> MSVC compiler in the build scripts so it handle __cplusplus in
> standard-compliant way:
>
>
>
https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
>
It seems that it's not that easy to pass this flag through CMake, and the
devs are not really willing to do something about it:
https://gitlab.kitware.com/cmake/cmake/-/issues/18837
We can do it. For instance add the flag in ./development/cmake/config.h.cmake
#cmakedefine LYX_EXTRA_CXXFLAGS 1
#if defined(LYX_EXTRA_CXXFLAGS)
#define ${LYX_EXTRA_CXXFLAGS}
#endif
Now you could use
$ cmake ... -DLYX_EXTRA_CXXFLAGS=__cplusplus
and the resulting config.h will contain
#define LYX_EXTRA_CXXFLAGS 1
#if defined(LYX_EXTRA_CXXFLAGS)
#define __cplusplus
#endif
Kornel
So, if it is possible then I commit the patch to nod library as my last
commit in this year :) Thanks Kornel and Thibaut.
Happy New Year to all LyX developers!
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Tuesday, December 29, 2020 11:32:39 PM WET José Abílio Matos wrote:
> There is just one note in here.
>
> I tried to compile the code using RHEL 7 that ships with gcc 4.8.5 and
> naturally the compilation fails here:
>
>
> insets/InsetListings.cpp: In member function 'virtual void
> lyx::InsetListings::latex(lyx::otexstream&, const lyx::OutputParams&)
> const':
>
> insets/InsetListings.cpp:230:31: error: 'strlen' was not declared in
this
> scope
>
> start += strlen("language=");
In case you want the full details they can be found here:
x86_64:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-x86_64/01850643-lyx-devel/build.log.gz
aarch64:
https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-aarch64/01850643-lyx-devel/build.log.gz
I am fairly clueless about such things. Fortunately, there are other
people who know more. JMarc? Enrico? Yuriy? Anyone?
Riki
I've updated only cmake check for GCC>=4.9. Seems like José uses
autotools. And Jean-Marc updated GCC version check in 3093789e8d, so he
is definitely the one who know more.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compilation error with MSVC 19
Here is a newer version of the patch that does not use _HAS_CXX17, as it should not really be relied upon ( https://stackoverflow.com/questions/52379233/is-has-cxx17-marco-usable-in-custom-project-headers-to-enable-c17-language). I think the right way will be using only standard-compliant "__cplusplus" in sources and adding the option "/Zc:__cplusplus" for MSVC compiler in the build scripts so it handle __cplusplus in standard-compliant way: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160 Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling in C++20 mode
I used "-k" instead of "-k0" (my make version does not seem to support "-k0". I
get the following errors with GCC:
/home/vbox/lyxbuilds/master-clang/repo/src/tex2lyx/Parser.cpp:857:34: error:
use of deleted function ‘std::basic_ostream&
std::operator<<(std::basic_ostream&, wchar_t) [with
_Traits = std::char_traits]’
857 | cerr << "ignoring a char: " << c << "\n";
| ^
/home/vbox/lyxbuilds/master-clang/repo/src/Buffer.cpp:1774:27: error: use of
deleted function ‘std::basic_ostream&
std::operator<<(std::basic_ostream&, wchar_t) [with _Traits =
std::char_traits]’
1774 | oss << "0x" << hex << e.failed_char << dec;
| ^~~
/home/vbox/lyxbuilds/master-clang/repo/src/Server.cpp: In lambda function:
/home/vbox/lyxbuilds/master-clang/repo/src/Server.cpp:869:40: error: implicit
capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Werror=deprecated]
869 | theApp()->registerSocketCallback(fd, [=](){
|^
Clang gives the following:
/home/vbox/lyxbuilds/master-clang/repo/src/tex2lyx/Parser.cpp:857:31: error:
overload resolution selected deleted operator '<<'
cerr << "ignoring a char: " << c << "\n";
~~~ ^ ~
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/system_error:262:5:
note: candidate function template not viable: no known conversion from
'lyx::char_type' (aka 'wchar_t') to 'const std:: error_code' for 2nd
argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
/home/vbox/lyxbuilds/master-clang/repo/src/Buffer.cpp:1774:22: error: overload
resolution selected deleted operator '<<'
oss << "0x" << hex << e.failed_char << dec;
~~ ^ ~
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/system_error:262:5:
note: candidate function template not viable: no known conversion from 'const
lyx::char_type' (aka 'const wchar_t') to 'const std::error_code' for 2nd
argument
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^
(this one is a warning)
/home/vbox/lyxbuilds/master-clang/repo/src/LyXRC.cpp:2950:28: error: comparison
between two arrays is deprecated; to compare array addresses, use unary '+' to
decay operands to pointers [-Werror,-Wdeprecated- array-compare]
|| lyxrc_orig.font_sizes != lyxrc_new.font_sizes
~ ^
/home/vbox/lyxbuilds/master-clang/repo/src/tex2lyx/Parser.cpp:857:31: error:
overload resolution selected deleted operator '<<'
cerr << "ignoring a char: " << c << "\n";
~~~ ^ ~
No problem if you can't take a look at all or any of these. Also, let me
know if for the next time you prefer for me to attach complete logs,
rather than just the error lines. Thanks for working on this, Yuriy!
Scott
I've fixed these errors (leaving warning fix for future), error lines
are enough so no need in complete logs. Does it compiles on your system now?
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Compilation error with MSVC 19
I just tried to recompile LyX on MSVC 19, this is the error I get:
[ 40%] Building CXX object
src/frontends/qt/CMakeFiles/frontend_qt.dir/GuiApplication.cpp.obj
GuiApplication.cpp
D:\LyX\lyx-unstable\3rdparty\nod\nod.hpp(272): error C2653: 'result_of': is
not a class or namespace name
D:\LyX\lyx-unstable\3rdparty\nod\nod.hpp(323): note: see reference to class
template instantiation 'nod::signal_accumulator' being compiled
D:\LyX\lyx-unstable\3rdparty\nod\nod.hpp(272): error C2146: syntax error:
missing ';' before identifier 'type'
D:\LyX\lyx-unstable\3rdparty\nod\nod.hpp(272): error C4430: missing type
specifier - int assumed. Note: C++ does not support default-int
It looks like it's due to bda45704005d6b328e18457a07d05e56883c2874, with
the replacement of boost::signals2 (a heavy library) by nod (an
unmaintained library). It's about things that are getting deleted in the
latest versions of C++, meaning that it will probably bite other compilers
at some point in the future.
As the author of the library did not answer to PRs in the last two years,
I'm not sure it's possible to upstream changes to it… What would be best in
this case?
I assume that you are compiling LyX in C++20 mode since `result_of` is
only deprecated in C++17. Does the attached patch resolves this issue?
(It is strange, but seems like result_of still exists in C++20 mode of
GCC...)
The nod library is pretty small and I suppose the only maintenance will
be due to backward incompatibilities of newer C++ standards.
Yuriy
diff --git a/3rdparty/nod/nod.hpp b/3rdparty/nod/nod.hpp
index 5c4a93cb85..86492d6d00 100644
--- a/3rdparty/nod/nod.hpp
+++ b/3rdparty/nod/nod.hpp
@@ -269,7 +269,11 @@ namespace nod {
{
public:
/// Result type when calling the accumulating function
operator.
- using result_type = typename std::result_of::type;
+#if __cplusplus >= 201703L
+ using result_type = typename std::invoke_result::type;
+#else
+ using result_type = typename std::result_of::type;
+#endif
/// Construct a signal_accumulator as a proxy to a
given signal
//
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling in C++20 mode
Thanks, Yuriy. I now get the following error with GCC: /home/vbox/lyxbuilds/master-clang/repo/src/Buffer.cpp:1774:27: error: use of deleted function ‘std::basic_ostream& std::operator<<(std::basic_ostream&, wchar_t) [with _Traits = std::char_traits]’ 1774 | oss << "0x" << hex << e.failed_char << dec; | ^~~ Scott It is the same error, we need static_cast(...) here too. If you'll add option "-k0" when doing build, then we'll be able to see all such errors at once and not one by one. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix C++20 warning on implicit capture of this via [=]
Hi Yuriy,
Apple clang spits this warning now - is it ok?
src/frontends/qt/GuiLyXFiles.cpp:200:16: warning: explicit capture of 'this'
with a capture default of '=' is a C++2a extension [-Wc++2a-extensions]
filesLW, [=, this](){ focusAndHighlight(filesLW); });
These now appear with gcc 8.3:
CXX GuiBibtex.o
GuiBibtex.cpp: In constructor
'lyx::frontend::GuiBibtex::GuiBibtex(lyx::frontend::GuiView&)':
GuiBibtex.cpp:116:27: warning: explicit by-copy capture of 'this' redundant
with by-copy capture default
availableLV, [=, this](){ focusAndHighlight(availableLV); });
^~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-deprecated-copy'
CXX GuiCitation.o
GuiCitation.cpp: In constructor
'lyx::frontend::GuiCitation::GuiCitation(lyx::frontend::GuiView&)':
GuiCitation.cpp:160:27: warning: explicit by-copy capture of 'this' redundant
with by-copy capture default
availableLV, [=, this](){ focusAndHighlight(availableLV); });
^~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-deprecated-copy'
CXX GuiDocument.o
GuiDocument.cpp: In constructor
'lyx::frontend::GuiDocument::GuiDocument(lyx::frontend::GuiView&)':
GuiDocument.cpp:1676:35: warning: explicit by-copy capture of 'this' redundant
with by-copy capture default
modulesModule->availableLV, [=, this](){
focusAndHighlight(modulesModule->availableLV); });
^~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-deprecated-copy'
CXX GuiLyXFiles.o
GuiLyXFiles.cpp: In constructor
'lyx::frontend::GuiLyXFiles::GuiLyXFiles(lyx::frontend::GuiView&)':
GuiLyXFiles.cpp:200:16: warning: explicit by-copy capture of 'this' redundant
with by-copy capture default
filesLW, [=, this](){ focusAndHighlight(filesLW); });
^~~~
At global scope:
cc1plus: warning: unrecognized command line option '-Wno-deprecated-copy'
CXX GuiRef.o
GuiRef.cpp: In constructor
'lyx::frontend::GuiRef::GuiRef(lyx::frontend::GuiView&)':
GuiRef.cpp:70:22: warning: explicit by-copy capture of 'this' redundant with
by-copy capture default
refsTW, [=, this](){ focusAndHighlight(refsTW); });
^~~~
Pavel
Fixed. Now all compilers should be happy.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling in C++20 mode
I'm not sure how this line compiled at all with earlier standards on Linux (where char_type is wchar_t). How wchar_t was outputted into char stream? It produced the integer value before C++20: https://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt2 So, the patch attached here should work as in earlier standards. Yuriy diff --git a/src/mathed/MathParser.cpp b/src/mathed/MathParser.cpp index dd43dd9eac..478e906308 100644 --- a/src/mathed/MathParser.cpp +++ b/src/mathed/MathParser.cpp @@ -370,9 +370,9 @@ ostream & operator<<(ostream & os, Token const & t) os << '\\' << to_utf8(cs); } else if (t.cat() == catLetter) - os << t.character(); + os << static_cast(t.character()); else - os << '[' << t.character() << ',' << t.cat() << ']'; + os << '[' << static_cast(t.character()) << ',' << t.cat() << ']'; return os; } -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling in C++20 mode
Thanks for working on this, Yuriy! I'm not sure if the following is helpful, but curent master fails for me with GCC and Clang with C++20 on Ubuntu 20.10. Here are details in case you or anyone else is motivated to take a look: /home/vbox/lyxbuilds/master-clang/repo/src/mathed/MathParser.cpp:373:21: error: use of deleted function ‘std::basic_ostream& std::operator<<(std::basic_ostream&, wchar_t) [with _Traits = std::char_traits]’ 373 | os << t.character(); Clang gives the following: [ 72%] Building CXX object src/mathed/CMakeFiles/mathed.dir/MathParser.cpp.o cd /home/vbox/lyxbuilds/master-clang/CMakeBuild/src/mathed && /usr/bin/clang++ -DBOOST_USER_CONFIG="" -DHUNSPELL_STATIC -DQT_CORE_LIB -I/home/vbox/lyxbuilds/master-clang/CMakeBuild -I/home/vbox/lyxbui lds/master-clang/repo/src -I/usr/include/enchant-2 -I/home/vbox/lyxbuilds/master-clang/repo/3rdparty/hunspell/1.7.0/src/hunspell -I/home/vbox/lyxbuilds/master-clang/repo/3rdparty/hunspell/1.7.0/src -I/home/vbox/lyxbuilds/master-clang/repo/3rdparty/boost -I/home/vbox/lyxbuilds/master-clang/repo/3rdparty/nod -I/home/vbox/lyxbuilds/master-clang/repo/src/mathed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/inclu de/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -Wall -Wextra -Wno-deprecated-copy --std=c++20 -Wno-deprecated-register -DENABLE_ASSERTIONS=1 -D_GLIBCXX_DEBUG -D_GLIBCXX_ DEBUG_PEDANTIC -fno-strict-aliasing -O0 -g3 -D_DEBUG -Werror -fPIC -std=c++2a -o CMakeFiles/mathed.dir/MathParser.cpp.o -c /home/vbox/lyxbuilds/master-clang/repo/src/mathed/MathParser.cpp /home/vbox/lyxbuilds/master-clang/repo/src/mathed/MathParser.cpp:373:6: error: overload resolution selected deleted operator '<<' os << t.character(); ~~ ^ ~ $ g++ --version g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ clang++ --version Ubuntu clang version 11.0.0-2 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Scott Hi Scott, Please try the attached patch. I'm not sure how this line compiled at all with earlier standards on Linux (where char_type is wchar_t). How wchar_t was outputted into char stream? Yuriy diff --git a/src/mathed/MathParser.cpp b/src/mathed/MathParser.cpp index dd43dd9eac..8659b59576 100644 --- a/src/mathed/MathParser.cpp +++ b/src/mathed/MathParser.cpp @@ -370,9 +370,9 @@ ostream & operator<<(ostream & os, Token const & t) os << '\\' << to_utf8(cs); } else if (t.cat() == catLetter) - os << t.character(); + os << to_utf8(docstring(1, t.character())); else - os << '[' << t.character() << ',' << t.cat() << ']'; + os << '[' << to_utf8(docstring(1, t.character())) << ',' << t.cat() << ']'; return os; } -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Drop QT4 from master
Could it be that this is why boost::regex was useful after all? Did we rush too fast in our joy of getting rid of it? I do not think that solving issues with crappy compilers involves going all the way in Qt's arms. Qt does have its flaws and bugs, and besides banging our head against the walls, there is not much we can do to cure it. Qt does not follow a standard, it is just Qt. Is it supposed to clear the screen before calling paintEvent? Nobody knows. Does it tell you when the system keyboard is switched? Your guess is as good as mine. This is where relying on standards is good. There is correct behavior and incorrect behavior. How do we find a good std::regex implementation for windows? Is there a compiler version that works? Is there an alternative std c++ library we can use? These are better questions than running towards an hypothetical saviour. I'm rambling, looks like it is time to go to bed. JMarc Seems like boost::regex has the same issues as std::regex: https://www.boost.org/doc/libs/1_75_0/libs/regex/doc/html/boost_regex/unicode.html As I understand the ICU library is the only ultimate solution for Unicode support. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] CRC-32 from zlib
Looks like a good idea. Note that we have in our tree zlib 1.2.8; dunno what part of the code is using it, but there have been several bugfix releases since then (currently 1.2.11). Pavel As I see we already have latest 1.2.11 in master branch. So I'm committing the patch. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling in C++20 mode
Tried at ab7ac800. At least it should be compilable with any c++ compiler.
Kornel
Now LyX can be successfully compiled with C++20 compiler. The attached
patch fixes C++20-specific deprecation warning (`this` in lambdas must
be captured explicitly), it should not affect earlier C++ versions.
Yuriy
From 2f1c206c72a6eca082f4402b8406cd028c01faf1 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 28 Dec 2020 20:59:48 +0200
Subject: [PATCH] Fix C++20 warning on implicit capture of this via [=]
---
src/frontends/qt/GuiBibtex.cpp | 2 +-
src/frontends/qt/GuiCitation.cpp | 2 +-
src/frontends/qt/GuiDocument.cpp | 2 +-
src/frontends/qt/GuiLyXFiles.cpp | 2 +-
src/frontends/qt/GuiRef.cpp| 2 +-
src/graphics/GraphicsCacheItem.cpp | 2 +-
src/insets/InsetExternal.cpp | 2 +-
src/insets/InsetInclude.cpp| 4 ++--
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/frontends/qt/GuiBibtex.cpp b/src/frontends/qt/GuiBibtex.cpp
index a9e0e45c55..22b704ed76 100644
--- a/src/frontends/qt/GuiBibtex.cpp
+++ b/src/frontends/qt/GuiBibtex.cpp
@@ -113,7 +113,7 @@ GuiBibtex::GuiBibtex(GuiView & lv)
availableLV, SLOT(setFocus()));
#else
connect(filter_, &FancyLineEdit::downPressed,
- availableLV, [=](){ focusAndHighlight(availableLV); });
+ availableLV, [=, this](){ focusAndHighlight(availableLV); });
#endif
availableLV->setToolTip(formatToolTip(qt_("This list consists of all
databases that are indexed by LaTeX and thus are found without a file path. "
diff --git a/src/frontends/qt/GuiCitation.cpp b/src/frontends/qt/GuiCitation.cpp
index b2656b132a..9ff03f30a0 100644
--- a/src/frontends/qt/GuiCitation.cpp
+++ b/src/frontends/qt/GuiCitation.cpp
@@ -157,7 +157,7 @@ GuiCitation::GuiCitation(GuiView & lv)
availableLV, SLOT(setFocus()));
#else
connect(filter_, &FancyLineEdit::downPressed,
- availableLV, [=](){ focusAndHighlight(availableLV); });
+ availableLV, [=, this](){ focusAndHighlight(availableLV); });
#endif
connect(regexp_, SIGNAL(triggered()),
this, SLOT(regexChanged()));
diff --git a/src/frontends/qt/GuiDocument.cpp b/src/frontends/qt/GuiDocument.cpp
index c21c3a00a0..4b9bdff5cc 100644
--- a/src/frontends/qt/GuiDocument.cpp
+++ b/src/frontends/qt/GuiDocument.cpp
@@ -1673,7 +1673,7 @@ GuiDocument::GuiDocument(GuiView & lv)
modulesModule->availableLV, SLOT(setFocus()));
#else
connect(filter_, &FancyLineEdit::downPressed,
- modulesModule->availableLV, [=](){
focusAndHighlight(modulesModule->availableLV); });
+ modulesModule->availableLV, [=, this](){
focusAndHighlight(modulesModule->availableLV); });
#endif
diff --git a/src/frontends/qt/GuiLyXFiles.cpp b/src/frontends/qt/GuiLyXFiles.cpp
index f14369a5a9..7859d4816d 100644
--- a/src/frontends/qt/GuiLyXFiles.cpp
+++ b/src/frontends/qt/GuiLyXFiles.cpp
@@ -197,7 +197,7 @@ GuiLyXFiles::GuiLyXFiles(GuiView & lv)
filesLW, SLOT(setFocus()));
#else
connect(filter_, &FancyLineEdit::downPressed,
- filesLW, [=](){ focusAndHighlight(filesLW); });
+ filesLW, [=, this](){ focusAndHighlight(filesLW); });
#endif
filterBarL->addWidget(filter_, 0);
diff --git a/src/frontends/qt/GuiRef.cpp b/src/frontends/qt/GuiRef.cpp
index 39f97eab27..6cdd7c8aaa 100644
--- a/src/frontends/qt/GuiRef.cpp
+++ b/src/frontends/qt/GuiRef.cpp
@@ -67,7 +67,7 @@ GuiRef::GuiRef(GuiView & lv)
refsTW, SLOT(setFocus()));
#else
connect(filter_, &FancyLineEdit::downPressed,
- refsTW, [=](){ focusAndHighlight(refsTW); });
+ refsTW, [=, this](){ focusAndHighlight(refsTW); });
#endif
filterBarL->addWidget(filter_, 0);
diff --git a/src/graphics/GraphicsCacheItem.cpp
b/src/graphics/GraphicsCacheItem.cpp
index 918dc02857..49132cc33b 100644
--- a/src/graphics/GraphicsCacheItem.cpp
+++ b/src/graphics/GraphicsCacheItem.cpp
@@ -220,7 +220,7 @@ void CacheItem::Impl::startMonitor()
return;
monitor_ = FileSystemWatcher::activeMonitor(filename_);
// Disconnected at the same time as this is destroyed.
- monitor_->connect([=](bool /* exists */){ startLoading(); });
+ monitor_->connect([this](bool /* exists */){ startLoading(); });
}
diff --git a/src/insets/InsetExternal.cpp b/src/insets/InsetExternal.cpp
index 655371ee9d..42918ec81d 100644
--- a/src/insets/InsetExternal.cpp
+++ b/src/insets/InsetExternal.cpp
@@ -656,7 +656,7 @@ void InsetExternal::updatePreview() const
renderer_ = make_unique(this);
RenderMonitoredPreview * preview_ptr =
renderer_->asMonitoredPreview();
// This connection is closed at the same time as this is
destroyed.
- preview
[PATCH] Update Doxygen options to have more dependency graphs
From 4f38e801eb930ca70b6a086f0aa553e1d19b21a3 Mon Sep 17 00:00:00 2001 From: Yuriy Skalko Date: Tue, 22 Dec 2020 12:14:00 +0200 Subject: [PATCH 6/7] Update Doxygen options to have more dependency graphs Now many graphs are not generated due to excessive dependencies (default node limit for one graph is 50). --- sourcedoc/Doxyfile.in | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sourcedoc/Doxyfile.in b/sourcedoc/Doxyfile.in index 921a2f63cc..ca522649d3 100644 --- a/sourcedoc/Doxyfile.in +++ b/sourcedoc/Doxyfile.in @@ -310,10 +310,9 @@ INPUT = @top_srcdir@/src # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp # *.h++ *.idl *.odl -FILE_PATTERNS = *.C \ +FILE_PATTERNS = *.cpp \ *.h \ - *.c \ -*.cpp + *.c # The RECURSIVE tag can be used to turn specify whether or not subdirectories # should be searched for input files as well. Possible values are YES and NO. @@ -879,6 +878,8 @@ GENERATE_LEGEND= YES DOT_CLEANUP= YES +DOT_GRAPH_MAX_NODES= 200 + #--- # Configuration::addtions related to the search engine #--- -- 2.28.0.windows.1 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[PATCH] CRC-32 from zlib
zlib has implementation of crc32 algorithm, I've used it instead of
Boost's one.
Now another part of Boost can be thrown away :)
Yuriy
From ec7563f53dc84f80bef4ba067a61d7ec5a9d4bac Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sat, 26 Dec 2020 21:23:44 +0200
Subject: [PATCH 7/7] Use crc32 calculation from zlib instead of boost
---
src/support/FileName.cpp | 4 ++--
src/support/checksum.cpp | 25 +
src/support/checksum.h | 2 +-
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index 3d31c7d37c..5295741e1a 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -608,8 +608,8 @@ unsigned long FileName::checksum() const
return 0;
}
- char * beg = static_cast(mm);
- char * end = beg + info.st_size;
+ unsigned char * beg = static_cast(mm);
+ unsigned char * end = beg + info.st_size;
result = support::checksum(beg, end);
diff --git a/src/support/checksum.cpp b/src/support/checksum.cpp
index 79ef955ce3..2249ad14e0 100644
--- a/src/support/checksum.cpp
+++ b/src/support/checksum.cpp
@@ -9,9 +9,10 @@
* Full author contact details are available in file CREDITS.
*/
+#include
#include "support/checksum.h"
-#include "boost/crc.hpp"
-#include
+
+#include
namespace lyx {
@@ -19,9 +20,8 @@ namespace support {
unsigned long checksum(std::string const & s)
{
- boost::crc_32_type crc;
- crc.process_bytes(s.c_str(), s.size());
- return crc.checksum();
+ auto p = reinterpret_cast(s.c_str());
+ return crc32(0, p, s.size());
}
unsigned long checksum(std::ifstream & ifs)
@@ -29,16 +29,17 @@ unsigned long checksum(std::ifstream & ifs)
std::istreambuf_iterator beg(ifs);
std::istreambuf_iterator end;
- boost::crc_32_type crc;
- crc = for_each(beg, end, crc);
- return crc.checksum();
+ unsigned long sum = 0;
+ for (auto & it = beg; beg != end; ++it) {
+ unsigned char c = *it;
+ sum = crc32(sum, &c, 1);
+ }
+ return sum;
}
-unsigned long checksum(char const * beg, char const * end)
+unsigned long checksum(unsigned char const * beg, unsigned char const * end)
{
- boost::crc_32_type crc;
- crc.process_block(beg, end);
- return crc.checksum();
+ return crc32(0, beg, end - beg);
}
} // namespace support
diff --git a/src/support/checksum.h b/src/support/checksum.h
index ab14339765..0533c57d79 100644
--- a/src/support/checksum.h
+++ b/src/support/checksum.h
@@ -21,7 +21,7 @@ namespace support {
unsigned long checksum(std::string const & s);
unsigned long checksum(std::ifstream & ifs);
-unsigned long checksum(char const * beg, char const * end);
+unsigned long checksum(unsigned char const * beg, unsigned char const * end);
} // namespace support
--
2.28.0.windows.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: InsetParams refactoring
Here is an update to my previous patch. I've separated it into several
patches. The next step will be moving `string2params` into InsetParams.
Please review these patches.
Yuriy
From f8a2c8a143bd54cec1da51b611e0a66c4af3305e Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 6 Dec 2020 11:24:01 +0200
Subject: [PATCH 1/7] Extract InsetParams superclass
---
src/Makefile.am| 1 +
src/insets/Inset.h | 1 +
src/insets/InsetBox.h | 6 ++---
src/insets/InsetBranch.h | 6 ++---
src/insets/InsetCommandParams.h| 7 +++---
src/insets/InsetFloat.h| 6 ++---
src/insets/InsetIPAMacro.h | 6 ++---
src/insets/InsetIndex.h| 6 ++---
src/insets/InsetListings.h | 2 +-
src/insets/InsetListingsParams.cpp | 4 ++--
src/insets/InsetListingsParams.h | 8 +++
src/insets/InsetNewline.h | 6 ++---
src/insets/InsetNewpage.h | 6 ++---
src/insets/InsetNote.h | 6 ++---
src/insets/InsetParams.h | 36 ++
src/insets/InsetPhantom.h | 6 ++---
src/insets/InsetScript.h | 6 ++---
src/insets/InsetSeparator.h| 6 ++---
src/insets/InsetSpace.h| 6 ++---
src/insets/InsetWrap.h | 6 ++---
20 files changed, 88 insertions(+), 49 deletions(-)
create mode 100644 src/insets/InsetParams.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 31701f2fb1..7dec8a1a6d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -639,6 +639,7 @@ HEADERFILESINSETS = \
insets/InsetNewpage.h \
insets/InsetNomencl.h \
insets/InsetNote.h \
+ insets/InsetParams.h \
insets/InsetPhantom.h \
insets/InsetQuotes.h \
insets/InsetRef.h \
diff --git a/src/insets/Inset.h b/src/insets/Inset.h
index ab2c535e46..4c637d19aa 100644
--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -17,6 +17,7 @@
#include "ColorCode.h"
#include "InsetCode.h"
+#include "InsetParams.h"
#include "LayoutEnums.h"
#include "OutputEnums.h"
#include "OutputParams.h"
diff --git a/src/insets/InsetBox.h b/src/insets/InsetBox.h
index cc80da3ecd..a0a2334df9 100644
--- a/src/insets/InsetBox.h
+++ b/src/insets/InsetBox.h
@@ -21,15 +21,15 @@
namespace lyx {
-class InsetBoxParams
+class InsetBoxParams : public InsetParams
{
public:
///
explicit InsetBoxParams(std::string const &);
///
- void write(std::ostream & os) const;
+ void write(std::ostream & os) const override;
///
- void read(Lexer & lex);
+ void read(Lexer & lex) override;
///
std::string type;
diff --git a/src/insets/InsetBranch.h b/src/insets/InsetBranch.h
index 6106ce5a5c..fdde0a1816 100644
--- a/src/insets/InsetBranch.h
+++ b/src/insets/InsetBranch.h
@@ -16,7 +16,7 @@
namespace lyx {
-class InsetBranchParams {
+class InsetBranchParams : public InsetParams {
public:
///
explicit InsetBranchParams(docstring const & b = docstring())
@@ -24,9 +24,9 @@ public:
InsetBranchParams(docstring const & b, bool i)
: branch(b), inverted(i) {}
///
- void write(std::ostream & os) const;
+ void write(std::ostream & os) const override;
///
- void read(Lexer & lex);
+ void read(Lexer & lex) override;
///
docstring branch;
///
diff --git a/src/insets/InsetCommandParams.h b/src/insets/InsetCommandParams.h
index 1800fb599d..4e417ad94d 100644
--- a/src/insets/InsetCommandParams.h
+++ b/src/insets/InsetCommandParams.h
@@ -15,6 +15,7 @@
#define INSETCOMMANDPARAMS_H
#include "InsetCode.h"
+#include "InsetParams.h"
#include "support/docstring.h"
@@ -115,7 +116,7 @@ private:
};
-class InsetCommandParams {
+class InsetCommandParams : public InsetParams {
public:
/// Construct parameters for inset of type \p code.
explicit InsetCommandParams(InsetCode code);
@@ -128,11 +129,11 @@ public:
///
InsetCode code() const { return insetCode_; }
/// Parse the command
- void read(Lexer &);
+ void read(Lexer &) override;
///
void Read(Lexer &, Buffer const *);
///
- void write(std::ostream &) const;
+ void write(std::ostream &) const override;
///
void Write(std::ostream & os, Buffer const * buf) const;
/// Build the complete LaTeX command
diff --git a/src/insets/InsetFloat.h b/src/insets/InsetFloat.h
index 0fc0fba398..daa5b3181d 100644
--- a/src/insets/InsetFloat.h
+++ b/src/insets/InsetFloat.h
@@ -21,16 +21,16 @@ namespace lyx {
struct TexString;
-class InsetFloatParams
+class InsetFloatParams : public InsetParams
{
public:
///
InsetFloatParams() : type("senseless&qu
