Keep track of nested includes and just refuse to re-enter a file
we're already in the process of handling.
There's a question whether we should do this in updateBuffer and
validate, or whether we should do it separately. For now, this seems
to work.
This is a mode for includeonly handling that is effective and still outputs
at least mostly correct counters and references. This is intended for non-
final editing work.
File format change.
First, we do not need to run bibtex/biber on the maintenance run, as
the necessary references will be generated on the includeonly run.
Second, exclude the master from DepTable in maintenance run, as the
master is re-checked in any case in the includeonly run, and as it will
always be detected as changed due to the \includeonly statement, which
will trigger a complete build.
More improvements to follow.
This is a reimplementation of 6d4e6aad that is both simpler and more
complete.
This uses the updateBuffer mechanism to implement a fully working
version of Inset::isChanged(). Now the function returns true for an
inset that contains an inset that contains a change, for example.
Moverover Buffer::areChangesPresent() is merely a proxy for
Buffer::inset().isChanged().
We will replace this with a better solution
For now, only keep
- Changes::isChanged()
- Buffer::areChangesPresent(), replaced by a dummy function
Next step will be to provide a working areChangesPresent() and to
compute Inset::isChanged in updateBuffer.
This reverts commit 6d4e6aad24.
When used as an adjective, both variants "descendent" and
"descendant" are acceptable, but when used as a noun only
"descendant" should be used.
For a reference, see here:
https://en.wiktionary.org/wiki/descendent#Noun
This bug provides two features:
1/ when a new document is created the language is set to the current
keyboard language.
2/ when keyboard is switched at OS level, the input language of
current window is changed. The language is set preferably to one of
those of the document. Ex. if the keyboard changes to en_GB but one
is typing a document in US English and Hebrew, then US English will
be selected rather that adding UK English to the list.
The implementation depends a lot on Qt. The platform status is :
* working on Windows 10
* not working with Linux (although 1/ works with Qt4); it seems that
Qt5 supports switching through ibus, but I do not know what this
means.
* not yet tested on macOS.
This addresses bugs #6450, #6247 and somehow #10514.
LyX follows LaTeX in dropping support for this combination
(it only worked by tricking "inputenc.sty").
There is no known case where this combination is required or helpfull.
For power users with special needs, XeTeX + TeX fonts is still
available after setting the input encoding to "ascii" or "utf8-plain".
See also #10600.
This revives a patch by Uwe and extends it. Additional options to font
packages/fontspec can now be entered in Document Settings.
This is principally also true for TeX fonts, if the new TeXFont tag
MoreOptions is set. For the time being, I have only done this for
MinionPro, as a model and prove of concept.
Note that adding more TeXFonts requires a file format change,
respectively, and changes to tex2lyx (in the same way as I've done for
MinionPro).
This addresses #8226
Now we report these in the same way as LaTeX errors (but let the user to
see the result anyway). It remains to be shown much is this disturbing
to users. Generally, ignoring these is not a good idea, because they are
harder to manually spot in longer documents.
The details of reported error varies because log linebreaks at 90
induced by pdflatex make log harder to parse.
The committed code is more robust than previous, in which some missing
cits/refs with long keys would go unnoticed.
Tested on bibtex and natbib.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg208912.html
See https://marc.info/?l=lyx-devel&m=155879185229073&w=2.
The problem is that, after saving the document and reloading, the
TOC is corrupted, more or less, when we run through updateBuffer.
So we reset it first.
Encoding cp858 supported by only some iconv variants.
Most users will want to change their "encoding" setting instead
of installing/recompiling "iconv" to support this legacy encoding.
ctests are likely will fail with either "vanilla" or "enhanced"
iconv and test a situation that is unlikely to change generally,
so we ignore this test now by default.
