This commit does a bulk fix of incorrect annotations (comments) at the
end of namespaces.
The commit was generated by initially running clang-format, and then
from the diff of the result extracting the hunks corresponding to
fixes of namespace comments. The changes being applied and all the
results have been manually reviewed. The source code successfully
builds on macOS.
Further details on the steps below, in case they're of interest to
someone else in the future.
1. Checkout a fresh and up to date version of src/
git pull && git checkout -- src && git status src
2. Ensure there's a suitable .clang-format in place, i.e. with options
to fix the comment at the end of namespaces, including:
FixNamespaceComments: true
SpacesBeforeTrailingComments: 1
and that clang-format is >= 5.0.0, by doing e.g.:
clang-format -dump-config | grep Comments:
clang-format --version
3. Apply clang-format to the source:
clang-format -i $(find src -name "*.cpp" -or -name "*.h")
4. Create and filter out hunks related to fixing the namespace
git diff -U0 src > tmp.patch
grepdiff '^} // namespace' --output-matching=hunk tmp.patch > fix_namespace.patch
5. Filter out hunks corresponding to simple fixes into to a separate patch:
pcregrep -M -e '^diff[^\n]+\nindex[^\n]+\n--- [^\n]+\n\+\+\+ [^\n]+\n' \
-e '^@@ -[0-9]+ \+[0-9]+ @@[^\n]*\n-\}[^\n]*\n\+\}[^\n]*\n' \
fix_namespace.patch > fix_namespace_simple.patch
6. Manually review the simple patch and then apply it, after first
restoring the source.
git checkout -- src
patch -p1 < fix_namespace_simple.path
7. Manually review the (simple) changes and then stage the changes
git diff src
git add src
8. Again apply clang-format and filter out hunks related to any
remaining fixes to the namespace, this time filter with more
context. There will be fewer hunks as all the simple cases have
already been handled:
clang-format -i $(find src -name "*.cpp" -or -name "*.h")
git diff src > tmp.patch
grepdiff '^} // namespace' --output-matching=hunk tmp.patch > fix_namespace2.patch
9. Manually review/edit the resulting patch file to remove hunks for files
which need to be dealt with manually, noting the file names and
line numbers. Then restore files to as before applying clang-format
and apply the patch:
git checkout src
patch -p1 < fix_namespace2.patch
10. Manually fix the files noted in the previous step. Stage files,
review changes and commit.
This reverts commit d568846e0331adc9a879c68b00c7dff901692dc7.
Unfortunately the used alternative API LSCopyDefaultApplicationURLForContentType
is available with 10.10 and later only and cannot be used therefore. So there
is no alternative to deprecated calls ATM. LyX 2.3 should run on 10.7 at least.
Seemingly, when removing an argument from argv, and thus inserting
a null pointer to shorten the array, causes an assertion because
the null pointer is not a valid heap pointer (sic!)
Fixes bug #10440
Other than BIBINPUTS, also BSTINPUTS and TEXFONTS are exported.
They do not replicate the setting for TEXINPUTS but are set such
that the current dir (i.e., the temp dir) and the document dir
are also searched for bibtex and fonts related files.
On startup, the default locale is "C", meaning that all system
functions assume an ascii codeset. The environment's locale
settings should be selected by calling setlocale(LC_ALL,"").
This is done by Qt during the QCoreApplication initialization
but this inizialization is never performed for batch processing
and, as a result, LyX is not able to process files whose names
contain non-ascii characters. This is not an issue on Windows,
where the file names are always stored as UTF-16, so the call is
only performed for unix-like platforms (this also includes cygwin,
due to its own filenames management that allows using characters
which are forbidden to native programs).
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?
variable. This is done in the preferences, much like as the PATH prefix.
A single '.' in the paths will get replaced with the current document dir
and also non-absolute paths will be prefixed with that dir.
The default semantics of TEXINPUTS apply, such that, for example, if a
path is terminated with a double slash, all subdirectories will be also
searched by both the TeX engine and ancillary programs such as dvi
previewers or dvips. As an example, if the prefix is set to ".:figs", the
TEXINPUTS variable will be set as ".:<docdir>:<docdir>/figs:$ORIGTEXINPUTS",
where <docdir> is the document directory.
The initial '.' is necessary to address the actual current dir (this will
be the temp dir at preview time), while if TEXINPUTS was initially unset,
such that $ORIGTEXINPUTS is empty, a colon (or semicolon on Windows) will
end the path list. This is very important, because we don't want to replace
the system directories but to complement them and, in order to do that, an
empty element has to be present in the list. Indeed, according to the
TEXINPUTS semantics, an empty element means the standard search path.
This works whether TEXINPUTS is originally set or not, because if the
original TEXINPUTS starts with a colon (meaning that the standard search
path is wanted there) we will have an empty element at that point,
otherwise the final colon will simply serve as a path separator.
Of course, on Windows a ';' has to be used as a path separator. LyX will
take care of transforming the platform path list into one understandable
by the TeX engine. For example, this will be the case for a Cygwin version
of LyX using a native Windows TeX engine or viceversa. I tested all of
this and it works for me.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38681 a592a061-630c-0410-9148-cb99ea01b6c8
Something went wrong with a script while previewing a document and now
I have to wait for 30 minutes for quitting LyX without killing it.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38578 a592a061-630c-0410-9148-cb99ea01b6c8
aka
Surrender to Windowsisms
aka
Resistance is futile, you will be assimilated
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34918 a592a061-630c-0410-9148-cb99ea01b6c8
and p2 == "Path/". This would be really weird, but one never knows...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29855 a592a061-630c-0410-9148-cb99ea01b6c8
The problem here is making sure that path_prefix_is() behaves exactly
as would a case insensitive prefixIs(). Anyway, this is still better
than trying to fix the semantics of common_path().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29846 a592a061-630c-0410-9148-cb99ea01b6c8
Now "lyx > stdout.log" should produce the same output as before
the switch to QProcess.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29655 a592a061-630c-0410-9148-cb99ea01b6c8
DVI viewer passes back the resolved path, such that the search fails,
as internally LyX uses the unresolved path.
This patch fixes this bug by using the new method FileName::realPath
which resolves a path by getting rid of any '.', '..', or symlink
path components.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29476 a592a061-630c-0410-9148-cb99ea01b6c8
* src/support/os*.{cpp,h}:
- new function is_valid_strftime that validates strftime arguments,
OS dependant (win32 differs here)
* src/Text3.cpp:
- use is_valid_strftime in LFUN_DATE_INSERT status check.
* src/frontends/qt4/GuiPrefs.{cpp, h}:
- new GUI validator for strftime.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28932 a592a061-630c-0410-9148-cb99ea01b6c8
hope there are only conforming implementaions out there ;-}
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21312 a592a061-630c-0410-9148-cb99ea01b6c8
xft-fonts package is still required. However, on *nix there seem
to be no way to tell fontconfig to prefer our fonts instead of
others matching the requirements, so, in case of conflict, the
fontconfig files should be manually adjusted, or some existing
font package used (note that the quality of the bakoma fonts is
better than that of the xft ones). There is no such problem on
Windows where our private fonts are always preferred over the
installed ones (and I hope the same holds true for Mac).
* src/LyX.cpp
(LyX::exec): don't call addFontResources() and restoreFontResources()
anymore, as the frontend code will do the job.
* src/frontends/qt4/GuiFontLoader.{cpp,h}
(GuiFontLoader::GuiFontLoader): register math fonts with Qt.
(GuiFontLoader::~GuiFontLoader): unregister math fonts.
* src/support/os.h
* src/support/os_unix.cpp
* src/support/os_win32.cpp
* src/support/os_cygwin.cpp:
remove code dealing with fonts.
* configure.ac: don't check for fontconfig headers anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@20128 a592a061-630c-0410-9148-cb99ea01b6c8
* src/support/os_unix.cpp
(addFontResources): add the system fonts dir to the paths
scanned by fontconfig.
(restoreFontResources): remove the system fonts dir from the
fontconfig configuration.
* configure.ac:
add check for the fontconfig devel headers.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@20034 a592a061-630c-0410-9148-cb99ea01b6c8
