Scott Kostyshak [Sun, 8 Apr 2018 21:35:09 +0000 (17:35 -0400)]
Refactor code showing error dialogs
This commit follows 8d2b121e and is not expected to change
functionality (e.g., I confirmed that the cases of #7330 and #11106
are still fixed). The advantages of this refactoring are the
following:
- Remove some preprocessor directives:
processingThreadFinished() is only called in the case that
EXPORT_in_THREAD is 1, so by moving some code up in the call list,
the directives are not needed.
- If errors() is called when there is no error, there will not be unexpected
behavior (e.g., as was the case before 8d2b121e).
Note that errors() is still only called by the code touched by this commit
if there is an error, but that is for efficiency and readability.
- The "from_master" argument now has a constant meaning. Before, it
could be the case that "from_master" was set to false but that the
master's error dialog was shown.
This allows (some) verbatim contents in macros, such as \url's with
specific chars (#, % etc.) in section headings or footnotes (#449)
or comments in captions (#9313).
The mentioned two bugs are fixed by this commit.
Note that the implementation is still rather basic and might need
extension for other cases.
Scott Kostyshak [Sat, 7 Apr 2018 21:11:33 +0000 (17:11 -0400)]
Do not show master's errors if compiling child
If a master document is compiled and has errors, and then a child is
compiled without error, the errors from the master compilation were
shown.
The setup of the relevant code is the following:
processingThreadFinished() calls errors(). errors() makes the
assumption that if it is called, there must have been an error
somewhere.
The logic of the setup is the following:
processingThreadFinished() knows whether there was an error on
the most recent preview/export, although it doesn't know whether
the error is from master or child (i.e. does not know whether the
user was compiling the child, or whether master-buffer-view was
called). Inside error(), if there is no error in the child, it is
assumed the error is from master.
For the above logic to work, errors() should only be called if there
was an error.
This commit fixes #11106 and preserves the fix to #7330.
When inserting math inset, put cursor selection in the correct cell
The original use case for this bug is entering an overset inset when
there is a selection. The expected result was to have the selection
pasted in main text, but the result was to have it in the cell.
Insets already have idxFirst() that is able to set cursor to the
"entry" cell of an inset. This patch introduces firstIdx(), which is
the index of this cell and uses it in idxFirst() (idem for
lastIdx/idxLast).
As a consequence, several instances of idxFirst/idxLast can be removed.
Now for the real fix: the two places where the cell in which selection
is inserted seem to be:
* Cursor::macroModeClose
* Cursor::handleNest
These two methods are changed to insert material in the entry cell
instead of cell 0.
idxFirst/Last methods are added to InsetMathRoot and InsetMathStackrel
so that the natural entry point is the nucleus of those insets.
Finallly, a typo is fixed in InsetMathNest::edit() where enter_front
computation was incorrect.
Kornel Benko [Fri, 30 Mar 2018 12:10:45 +0000 (14:10 +0200)]
Amend 8774ad5, Adapt to new hunspell C++ ABI for cmake
Replace CHECK_CXX_SOURCE_COMPILES() with TRY_COMPILE()
Discarding the link-stage mimics the behaviour used by automake.
Now the testsource is compiled regardless if hunspell
is external or not.
Kornel Benko [Thu, 29 Mar 2018 20:53:59 +0000 (22:53 +0200)]
Adapt to new hunspell C++ ABI for cmake
The compile test for 3rdparty hunspell is omitted,
because the macro check_cxx_source_compiles() tries also to link.
But at the time of the check, the required library is not there.
Compile 3rdparty/hunspell in stdlib-debug mode when needed
A function that returns a vector<string> will lead to a crash if the
main code and the library have not been compiled with the same
stdlib-debug state. See for example:
https://stackoverflow.com/questions/4764048/stl-and-release-debug-library-mess
This is fixed by introducing a new variable STDLIB_DEBUG that contains
the flags that trigger the debug mode (autoconf only for now).
Pavel Sanda [Thu, 22 Mar 2018 01:26:46 +0000 (02:26 +0100)]
esint10: attempt on to fix empty symbol glyphs.
With advent of qt5 glyphs on codepoints 10, 12, 13 can't be shown anymore.
In this patch we copy the glyph pairs to new codepoints:
dotsint: 19->41 (this one was already moved by Goerg, now moving to the same block)
oint: 11->43
oiint:13->45
I couldn't find fix where both qt4 & qt5 would show correct results,
so this patch fixes qt5 situation, but breaks qt4, which hopefully
won't be needed for master.
Testing and debuging is somewhat tricky, becuse qt sometimes prefer to
load global fonts in /usr/share while ignoring the local git tree.
To be continued in other fonts.
Related reports:
https://www.lyx.org/trac/ticket/8493
https://bugreports.qt.io/browse/QTBUG-66266
Kornel Benko [Thu, 15 Mar 2018 21:34:26 +0000 (22:34 +0100)]
Cmake export lyx* tests: Omit compilation of lyx16x, lyx20x and lyx21x exported files
These file don't contain the \\origin tag. So the possibly included
files with relative path would not be found. The compilation to
the default pdf would then anyway fail.
There are more independent crashes occuring in this scenario and this
fix targets only one of them, in particular the one in which different
window's outliner sends outliner command to a wrong window. The fix
itself gives an option for lfun to know which window it belongs to.
projects / lyx.git / log