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.
We open the input file now twice: The first time in latin1 encoding to read
the document encoding from the preamble. This does always work, since
traditional TeX does not allow non-ASCII contents without an encoding changing
command (except for comments, but we do not need them, and using latin1 rather
than utf8 ensures that they do not produce an iconv exception, but are simply
recored with wrong characters), and we do detect the utf8 based TeX engines
XeTeX and LuaTeX as well. The second time we open the file directly with the
document encoding.
This fixes a few tex2lyx tests on OS X, since changing the encoding of an
open file steam does not work with clang on OS X. Files using more than one
encoding are still broken, but all single-encoding files are fixed now.
Changing the codecvt_facet of a file stream after the file has been opened
does not work with clang on OS X. Therefore we avoid it if possible (i. e. the
new encoding is the same as the old one).
We claim that gcc 4.x is needed in INSTALL, so it does not make sense to keep
this old stuff. Instead, I made configure output an error if gcc is too old.
This resolves a dependency of src/support/docstream.cpp on src/TexRow.cpp,
which is the wrong way round. This fixes the linking
src/tests/check_ExternalTransforms with MSVC where the linker is not clever
enough to detect that the whole otexstream class is unused.
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
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
all types requiring the exact same code, as suggested by Tommaso.
This allows to simply add a single-line instantiation declaration
if there's the need of adding another type requiring the same code.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37366 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
// std::numpunct has a hardcoded dllimport in definition, but we wanna it with 32 bit
// so we can't import it and must define it but then the compiler complains.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34262 a592a061-630c-0410-9148-cb99ea01b6c8
tex2lyx woes under windows. It may also help chktex under windows
(does it works currently?)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29361 a592a061-630c-0410-9148-cb99ea01b6c8
Japanese char between math insets becomes wrong in TeX output
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28732 a592a061-630c-0410-9148-cb99ea01b6c8
encoded using 1 or 2 bytes, but it may be prefixed by 3-byte escape sequence.
So, a single ucs4 char could need a maximum of 5 bytes. I think that it
is better to be safe than sorry...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27645 a592a061-630c-0410-9148-cb99ea01b6c8
properly fix bugs 5216 and 5280. The best thing to do would be recognizing
at configure time a buggy iconv and #defining WORKAROUND_ICONV_BUG in
config.h, but I don't know how that could be done.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@27618 a592a061-630c-0410-9148-cb99ea01b6c8
* lib/encodings:
* src/support/docstream.h:
- JIS is not a valid iconv name. Rename to ISO-2022-JP
* src/output_latex.cpp:
- fix wrong encoding switch.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@25510 a592a061-630c-0410-9148-cb99ea01b6c8
- odocfstream: properly fix plaintext output by getting rid of ctor with std::string argument as this can be mixed up with std::ofstream(std::string) ctor where the argument is a file. UTF8 is now the default encoding.
- PreviewLoader::Impl::startLoading(): catch another potential iconv exception.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22332 a592a061-630c-0410-9148-cb99ea01b6c8
Now support/* should have no dependencies on src/* anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21851 a592a061-630c-0410-9148-cb99ea01b6c8
* src/support/docstream.{cpp,h}:
Move insertion operator for char types from docstream.h to
docstream.cpp and compile it only when USE_WCHAR_T is not defined.
* src/support/strfwd.h:
Implement forward declarations in standard C++ way.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21513 a592a061-630c-0410-9148-cb99ea01b6c8
- consider that not only utf8, but also most cjk encodings, are multibyte encodings
(fixes bug 4012)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@19076 a592a061-630c-0410-9148-cb99ea01b6c8
