QProcess::startDetached cannot provide environment variables. When the
environment variables are set using the latexEnvCmdPrefix, a console
window is shown every time a viewer is started.
On Windows, this reverts commit 5225821242.
Fixes: #9035.
it's easy to use the existing docstring routine, so I've commented
out the string version of lowercase I had introduced. I've left the
code in case someone else needs it later.
the name, in the hyperlink. Fixes bug #8792.
This also fixes a bug discovered while working on this code: The
params passed to GuiHyperlink were never used.
This is the result of the discussion on the list "2.1.0 Blocker". Thanks to
all contributors!
The main idea is to use thread-local storage for all static variables.
This solution does not need any mutex. For more details, see the comment in
unicode.h.
It is no longer needed, and it had a comment that it needed review...
Now anybody who tries to make a copy again is forced to think about it,
instead of trying and using possibly wrong semantics by accident.
The Messages::gui_lang_ variable is instantiated in the '#ifdef ENABLE_NLS' block. To prevent compile problems, we should also instantiate it when NLS is disabled.
Make sure that the configure script only checks features using the C++ compiler.
Also get rid of our last C files, since they are not compiled nor distributed anyway.
The path to the lyx binary is either <build_dir>/bin (CMake) or
<build_dir>/src (autotools). This means the po directory can be found one
directory up.
Since 00387b2a38 it is possible to construct a dummy Messages object
which does not translate at all. With the old gettext implementation, a
Messages object without a defined language would have used a language from
an environment variable. Therefore, the duplicate definition of _() is no
longer needed. This gettext removal was really a good idea!
This is done by handling explicitly a dummy Message object, where no parsing of mo file is attempted. This avoids in turn that the lyxerr object is used during initialization of a global dummy Message object.
With gettext, we have been forced to install .mo files at the right place in order to read them. Now that we have our code, the situation changes.
* Add new method Package::messages_file(code), when returns the right path, depending on whether we are running in place.
* In Messages class use that intead of the existing one.
Get the default language by a mix of QLocale and LyXRC::gui_language
Known limitations:
* encoding is supposed to be UTF-8 (the charset parameter is checked);
* context is not handled (implemented differently in LyX);
* plural forms not implemented (not used for now in LyX);.
* tThe byte endianness of the machine on which the .mo file have been
built is expected to be the same as the one of the machine where this
code is run.
When running the test, you'll get the following messages:
Testing ../../src/../lib/layouts/siamltex.layout...
Layout.cpp (268): Cannot copy unknown style `Enumerate'
Testing ../../src/../lib/layouts/svglobal.layout...
Cannot delete style `Dedication'
Testing ../../src/../lib/layouts/svjog.layout...
Cannot delete style `Dedication'
Testing ../../src/../lib/layouts/svprobth.layout...
Cannot delete style `Dedication'
These are no errors of Layout::write(), but they indicate problems in the
definition of the layout files.
Kornel, it would be nice if you could do the cmake part.
* report results in milliseconds instead of microseconds
* report total time spent in block, additionally to mean time
* cause compilation error with --enable-stdlib-debug
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
When using CMake, the binary files are stored in <build-dir>/bin. LyX can't fin tex2lyx with the current code. So, we have to point configure.py to explicitly look in the binary dir.
FileName::tempName() is not thread safe, since the QTemporaryFile object is
immediately deleted after creating it. Therefore, another thread could create
the same temporary file in the time span before the user of FileName::tempName()
recreates it. This is not as theoretical as it may look: I observed that
repeated creation and deletion of QTemporaryFile objects always use the same
name.
This problem is solved by the new class TempFile which should be used like
QTemporaryFile itself.
This will be needed for layout forward compatibility, and could also be used
for a layout editor. Writing was only implemented for styles, not for complete
layout files (text class). I rarely made use of default values for missing
variables which exist in read(), so the output it a bit verbose (but more safe
against future changes). Also, some things like CopyStyle are never written for
obvious reasons.
The use of this profiler is trivial:
* #include <support/pmprof.h>
* in the block one wants to profile, add
PROFILE_THIS_BLOCK(some_identifier)
* At the end of the execution, statistics will be sent to standard error.
so we can write a limited amount when using this for TOC and
tooltip output.
This should solve the problem with slowness that Kornel noticed,
which was caused by our trying to write an entire plaintext
bibliography every time we updated the TOC. We did that because
he had a bibliography inside a branch, and we use plaintext for
creating the tooltip that goes with the branch list.
Other related bugs were fixed along the way. E.g., it turns out
that, if someone had an InsetInclude inside a branch, then we would
have been writing a *plaintext file* for that inset every time we
updated the TOC. I wonder if some of the other reports of slowness
we have received might be due to this kind of issue?
- Use the LyX name of encodings instead of the LaTeX names.
The LyX name must be unique, while the name used by LaTeX
not necessarily, e.g. different packages might implement
support for the same encoding.
- Rename koi8 to koi8-r, so that the LyX and LaTeX names match.
- Rename euc-jp-plain to euc-jp-platex, jis-plain to jis-platex
and shift-jis-plain to shift-jis-platex.
- Add utf8-platex encoding (fixes#8408).
LyX file format incremented to 463.
The current code is not able to unset an environment variable, only to set it to an empty value. This patch refactors a bit the Message class and uses a new EnvChanger helper class that allows to change temporarily an environment variable and that is able to unset variables if needed.
The patch also adds new functions hasEnv and unsetEnv in environment.cpp.
Open issues:
* there may be systems where unsetenv is not available and putenv("name=") does not do the right thing;
* unsetenv may lead to leaks on some platforms.
* when using unsetenv, we may need to remove strings from the internal map that setEnv uses.
* some functionality is in new modules now
new header locations and library names: QtConcurrent and QtWidgets
* method setResizeMode is renamed to setSectionResizeMode
* deprecated QAbstractItemModel::reset() is dropped now
* platform specific code like QApplication::syncX() is not common anymore
* QString::fromAscii() is dropped now
* some QDesktopServices methods has been moved to QStandardPaths
This patch puts all projects into subfolders (at least for MSVS). In this
way, there is a better overview (especially if the number of test projects
will be increasing).
Next try to make it to work on APPLE (and maybe on WIN32)
a.) Create the needed data-dir at configure time
b.) Use different target names for executable and data created with them
A dummy getGuiMessages function was missing. Instead of adding it everywhere, a new file is created that contains all the dummy functions needed by the tests.
The previous scheme of loading all possible translations and checking
whether the work is a bit too much "brute force" and causes problems
on Mac OS X (documents loaded with the wrong language).
Now there is an helper static method in Messages class that checks
whether a readable .mo file exist for the language. There should be an
API in gettext for doing that, but alas it is not possible.
As a consequence the method Language::translated() has been removed,
along with its cache.
In order to interact with native osx applications, AppleScript support is a plus.
Here is a patch that makes LyX respond to a simple command (run) and that allows to communicate with LyX as with the LyX client.
Example of use:
tell application "LyX" to run "server-get-filename" with argument ""'
returns
message:/Users/bpiwowar/newfile1.lyx, code:0
with a message and the error code
The goal here is to get rid of the old code that modified variables
LANGUAGE and LC_ALL, therefore creating the problems mentionned
in the ticket.
In the new system, there is no explicit "GUI" message handler, that
needs to be reset at each language change. Instead, getGuiMessages
calls getMessages with the correct parameter. This allows to simplify
greatly the code and to remove a lot of old cruft.
objects. The problem that led to the leak is that these objects can be held in
memory long after the Buffer that created them is gone, mostly due to their
use in the CutStack. So they were previously held in a storage facility, the
DocumentClassBundle. Unfortunately, they were now being created too often,
especially by cloning. It's not really a leak, because they're accessible, but
we weren't ever destroying them.
This new approach uses a shared_ptr instead.
Thanks to Vincent for pointing out const_pointer_cast.
If no mask is supplied or the mask is attached to the end of the filename, we end up with unexpected names like
<system-temp-dir>\lyx_tmpdir.qHp780.vcr780_<mask>
instead of a temporary file in the lyx temporary directory like
<system-temp-dir>\lyx_tmpdir.qHp780\<mask>.vcr780.
The listings inset and include inset of type listings use two english terms
that are not localized yet: "Listing" for the caption and "Listings" for the
list of listings (not supported natively by LyX yet). The existing layout
translation mechanism has been extended to translate these terms as well:
1) Support [[stuff]] context in lib/layouttranslations
2) Support BabelPreamble and LangPreamble in InsetLayout
3) Use a InsetLayout for InsetInclude of type listings
4) Define BabelPreamble and LangPreamble in the layouts for InsetInclude
and InsetListings
Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.
Signed-off-by: Lars Gullik Bjønnes <larsbj@gullik.org>
overriding a pure virtual method (part of bug #8032).
I wonder why it was working on Windows and why it works for QString.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40783 a592a061-630c-0410-9148-cb99ea01b6c8
After the timeout elapses, the user is notified that a command is taking
a long time to complete and is given the choice to stop it. If the user
decides to let the command run, the timeout is increased, otherwise the
command is killed. One is prompted a first time after 3 mins, a second
time after 9 mins, a third time after 27 mins, and so on, i.e., the n-th
prompt occurs after 3^n minutes.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40775 a592a061-630c-0410-9148-cb99ea01b6c8
A real fix would be to ditch the home made file format detection and use libmagic.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40587 a592a061-630c-0410-9148-cb99ea01b6c8
This is a candidate for branch too, although the bug is minor.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40149 a592a061-630c-0410-9148-cb99ea01b6c8
Of course this will only work if output_changes was true when creating the
.tex file.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40139 a592a061-630c-0410-9148-cb99ea01b6c8
file names with a proper one: Only replace dots in the base name, and only
request the lyxdot feature if it is needed. This is a partial fix of bug #7650.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40115 a592a061-630c-0410-9148-cb99ea01b6c8
for later calls. The check is only performed on the major version
number, such as to avoid using python 3.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40049 a592a061-630c-0410-9148-cb99ea01b6c8
utf8 strings, and not only if they contain encoding changes. This is
because if the output encoding was previously changed and an utf8
string is inserted in the stream, the encoding changes cannot occur.
This was not a problem until now because normal strings could not be
inserted in a odocstream, as them would have been exchanged with encoding
changes. Indeed, the SetEnc struct has only a std::string member and
outputting a std::string would be interpreted by the compiler the same
as inserting setEncoding(std::string). However, a std::string can be
inserted in an otexstream and it is better to account for this.
I wonder whether trying "os << std::string", where os is an odocstream,
should produce an error instead of actually trying to change the stream
output encoding, but this has not been a problem until now...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39944 a592a061-630c-0410-9148-cb99ea01b6c8
and not for utf8 ones. But the simple solution is to convert to a
docstring before outputting to the underlying docstream.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39930 a592a061-630c-0410-9148-cb99ea01b6c8
on the fly are only available for ucs4 encoded strings and not for utf8
ones. So, it does only work with docstrings.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39928 a592a061-630c-0410-9148-cb99ea01b6c8
This restores \input@path handling, which turns out to be necessary, as
the TEXINPUTS mechanism is not used with relative paths. It turns out
that both methods must be used, because \input@path does not work in all
cases (most notably with tikz).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39918 a592a061-630c-0410-9148-cb99ea01b6c8
