Age | Commit message (Collapse) | Author |
|
In right-to-left paragraph mode, transliterate
Hungarian text word by word during typing, also
add the associated checkbox to Localized Options
page of AutoCorrect dialog window.
Old Hungarian (ISO 15924: Hung) is a historical
and renewed script which is still in use to
transliterate Hungarian writing.
As a localized AutoCorrect feature, the patch supports
the followings:
– word-by-word transliteration of Hungarian texts only
in right-to-left paragraph mode.
– consonant disambiguation of digraphs and trigraphs
based on hyphenation (now pattern-based Huhyphn
dictionary of libhyphen, planned dictionary based
Hunspell later)
– transliteration by extended hu-Hung module of
Numbertext library.
Note: transliteration of the selected text using
AutoCorrect Apply function has't been implemented, yet.
Change-Id: Iee0f18e2485c974c35acf0a3abc3a49c2cf80196
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95303
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry-picked from commit da64ec8c8a91db6a6ec9657898f081d5ee67e739)
Change-Id: If6639761278048d2fca61f7881a3287d38a1a313
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95378
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
This reverts LO6.4 commit 5cf057c3365a0feafc8f2e4f4a9e24d69a581999,
in order to fix tdf#133158.
This commit is obsolete, but was left in place since it
seemed to have fixed a problem (in =gtk3 anyway).
But now SAL_USE_VCLPLUGIN=gen behaves differently,
so obviously a fix in one place must have broken another.
Better the problems you have always known than
a new problem, especially since this patch
isn't used to fix anything specific in gtk3 anymore
(since those changes were also reverted).
An earlier gerrit version of this revert (which
didn't just have an ignore-this-clang-rule exception)
half-worked, but failed if multiple documents
were opened.
Change-Id: Ie8ddb7b9669fa46067d04c35e157ea08701df0da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95282
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit d5e222cd86b82a429c28cb19583521d581efaf2b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95311
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
in the document, looks like only the calc one actually works, and when
it works on large quantities of results calc grinds to a complete halt
This was introduced with:
commit b41332475783c31136673fb44cf4c411bb0148f8
Date: Mon Dec 2 15:54:29 2013 +0000
Integrate branch of IAccessible2
and has been a problem on and off with calc's potentially ~infinite grid
There is the on-by-default search results dialog in calc (which has a limit on
how many it shows) which provides an alternative route to iterate through the
results
Change-Id: I2685e480d2d15220be0bddbc83baad3992e7d5d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95006
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 0b94169d820482434dc98a37c3c1633ca46fd0dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95012
|
|
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...since <https://github.com/llvm/llvm-project/commit/
d0da5d2bbe8305d06dc01a98706fd73e11e24a9f> "Change default traversal in AST
Matchers to ignore invisible nodes". This caused failures
> [CPT] compilerplugins/clang/test/constparams.cxx
> ParmVarDecl 0x11d76c730 <compilerplugins/clang/test/constparams.cxx:15:12, col:18> col:18 used f1 'int *'
> DeclRefExpr 0x11d76c948 'int *' lvalue ParmVar 0x11d76c730 'f1' 'int *'
> ParmVarDecl 0x11d76cc80 <compilerplugins/clang/test/constparams.cxx:21:12, col:18> col:18 used f2 'int *'
> DeclRefExpr 0x11d76ce60 'int *' lvalue ParmVar 0x11d76cc80 'f2' 'int *'
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/constparams.cxx Line 15: this parameter can be const Class1::Class1 [loplugin:constparams]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/constparams.cxx Line 15: no parent? [loplugin:constparams]
> File compilerplugins/clang/test/constparams.cxx Line 21: no parent? [loplugin:constparams]
> 3 errors generated.
[...]
> [CPT] compilerplugins/clang/test/unusedenumconstants.cxx
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: read Bottom [loplugin:unusedenumconstants]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: write Bottom [loplugin:unusedenumconstants]
> 2 errors generated.
[...]
> [CPT] compilerplugins/clang/test/unusedfields.cxx
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/unusedfields.cxx Line 156 (directive at compilerplugins/clang/test/unusedfields.cxx:164): write m_f5 [loplugin:unusedfields]
> File compilerplugins/clang/test/unusedfields.cxx Line 210 (directive at compilerplugins/clang/test/unusedfields.cxx:211): read m_f1 [loplugin:unusedfields]
> 2 errors generated.
For compilerplugins/clang/test/constparams.cxx at least it would have worked to
fix that locally with
> diff --git a/compilerplugins/clang/constparams.cxx b/compilerplugins/clang/constparams.cxx
> index 95c8184009d7..70f056fa5a69 100644
> --- a/compilerplugins/clang/constparams.cxx
> +++ b/compilerplugins/clang/constparams.cxx
> @@ -274,7 +274,7 @@ bool ConstParams::checkIfCanBeConst(const Stmt* stmt, const ParmVarDecl* parmVar
> {
> for ( auto cxxCtorInitializer : cxxConstructorDecl->inits())
> {
> - if ( cxxCtorInitializer->getInit() == stmt)
> + if ( cxxCtorInitializer->getInit()->IgnoreImpCasts() == stmt)
> {
> if (cxxCtorInitializer->isAnyMemberInitializer())
> {
(somewhat unintuitively, given the Clang change is apparently about ignoring
more implicit nodes), but overall it appears better---at least for now---to use
a getParents variant that keeps the old traversal behavior.
For that, instead of using the clang::ASTContext::ParentMapCtx, we create our
own loplugin::Plugin::parentMapContext_. There appear to be no uses of
ASTContext::getParent across the Clang codebase itself, outside of ASTMatcher
code, so it looks unlikely that creating our own ParentMapContext instance would
degrade performance by no longer sharing cached data between Clang's internals
and our plugin. (And given that ASTContext::getParents is deprecated with the
note "New callers should use ParentMapContext::getParents() directly", this may
well be the correct way in the long run, anyway.)
Change-Id: I46c7912f2737e7c224fd45ab41441f69e2f10bd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94795
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I235e00eca7b7cbc070bf5831117868eba5c7c273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8961b5df1b3a7ea9b7dd83114fce1555b9e4ffcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94787
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1af2948e0332044ef88bc7dbd837e8c7afe7af19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94785
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Windows is now more or less the only platform where Skia gets used.
There's also the 'gen' VCL backend on Linux, but that one gets
used rarely and it's Skia options are still accessible in the expert
configuration.
Change-Id: Ibec9b8b15e9200f003367b4568432ce93ec63893
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94708
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
the FreetypeFont only makes sense in the context of the FreetypeFontInstance it
belongs to so remove the faux "garbage collection" and just have FreetypeFontInstance
own the FreetypeFont and keep it simple.
Setting a value low enough to make the garbage collection kick in just crasheed
libreoffice by pulling FreetypeFont out from under living FreetypeFontInstance
seeing as the Cache/Uncache was by the FreeTypeTextRenderImpl not the
FreetypeFontInstance which had HarfBuff faces which continued to point to the
removed FreetypeFont
There is still a cache at the LogicalFontInstance level, so this aligns the
libfreetype platforms with windows, mac etc.
Change-Id: Iac669fae8dc1df81a5bc10d2943d84a2ff623180
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94546
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If179d0a13f3c9f7a49e3efe9027a64368ed600a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94544
Tested-by: Jenkins
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa90e9721edeacd4fd78fde968b81aab873e2061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94497
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to 1d0bc2139759f087d50432f8a2116060676f34e1
"use std::experimental::source_location in uno::Exception"
Change-Id: I2b18dbae89c6f219edacba5d147ea265ca83725e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94422
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8796c0937fe4b046d9a13e2e50368e45e0e45611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94404
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I95391ef6ed5154efc2c7705dde22afa59da24a70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I52187eccf6170f64d38c673a86dc80818813efa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94328
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If0e362cf5b403be63439ec694f3a0e440dfd9bc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94327
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
LogicalFontInstance dtor does call hb_font_destroy though
Change-Id: I59d9711f1934966cddd73c5e62c8929f08b1359a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94335
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibb37c7e840a32453b1d52854d5f958c0285cd26a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94326
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0ec89b56b339f26bb236887c904e6b5d14ceecea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94136
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id813d95a90fdbb360dfc8670c0b55b635f633965
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to catch a few more cases
Change-Id: I0323fba51bb2b4ba255e1db5aa0d890c5c6a2e1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93726
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where the relevant types' actual names are std::__1::unique_ptr and
std::__1::default_delete
Change-Id: I2c364535061691415703d6ff0f58269cdd192a6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...<https://github.com/llvm/llvm-project/commit/
159a9f7e76307734bcdcae3357640e42e0733194> "[AST] Print a<b<c>> without extra
spaces in C++11 or later."
Change-Id: Ic8a2ab1ee9082e150cf0ebe1f6538a1a1deb7853
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93409
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to find places where we are converting stuff to unique_ptr
instead of using std::make_shared.
As a bonus, this tends to find places where we are using shared_ptr
where we can instead be using unique_ptr avoiding the locking overhead.
Change-Id: I1b57bbc4a6c766b48bba8e25a55161800e149f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8d0e10b08393b7752d55298e0e1ba64e5fd6c422
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93083
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
I need that for another upcoming commit.
Change-Id: If7e567c731e454070bf8ad9efb5c2f28ff9049e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93031
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
ref-counting traffic here accounts for 10% of the profile on some of my
calc imports.
Change-Id: I1b32e0e61d7bf5eb65780ec0e7fcb99f6576050a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92694
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6197d72ae136da04dfb22c847623004b797d75d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ba901c7d6e1e88d9d2821df4a37ebbea3b63084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92874
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iec5de34f908ac370302ab51a33f17dfc23ea2446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92834
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieec5099a8ce9fa3f07e36be244071efc1b101cf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92803
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Flash technology is going to be retired by the end of 2020 by Adobe:
https://theblog.adobe.com/adobe-flash-update/
With this ahead doesn't make much sense for LO 7.0 to support exporting
presentations and drawings to swf anymore.
Change-Id: Ic2c6e95db2f56bcd4eb25abdd0a6748aee9b0e4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92507
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I07f828e8a17de03cf15639df8afa0adf5dcaebba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92246
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
with custom row rendering
Change-Id: Ia909b5b9ad56b6ea4611e9ea0a1e2cb0064a8cd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91841
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Where the Optional ctor is explicit.
Change-Id: I577661c022f25502260977a6ef6744e4e178acc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92519
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
rather than asserting, write out a warning so that section of code can
be handled manually
Change-Id: I1356012f4e480cff9508dad6c2d70cbbba1a5dc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
More flexible dialog
logo & about images as SVGs
Change-Id: Icefa035893e241a7dee6aa28236e6b89b38477de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91908
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: Id14fed7e5c0f588ad3c927f12251432d12c1a7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92190
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...as is used by GCC trunk libstdc++ std::unique_ptr since <https://gcc.gnu.org/
git/?p=gcc.git;a=commitdiff;h=5b074864f8c593fd4bccee788a023a37b446b2ed>
"libstdc++: Add comparison operators to std::unique_ptr", which caused
unexpected warnings like
> sfx2/source/dialog/tabdlg.cxx:1057:17: error: parentheses immediately inside vardecl statement [loplugin:unnecessaryparen]
> bool bSet = ( m_pSet != nullptr );
> ^~~~~~~~~~~~~~~~~~~~~
(CXXRewrittenBinaryOperator was introduced with <https://github.com/llvm/
llvm-project/commit/778dc0f1d49230f53401ae0c190fe460bda4ffd1> "[c++20] Add
CXXRewrittenBinaryOperator to represent a comparison", which first appeared in
LLVM 10.)
Change-Id: I68024d975dc4accbfa9da855baa37bf9f990b99c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92061
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and workaround a clang crash
Change-Id: Ida94c8abb4b2e997d38a7f430e59f73aadf8fcc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91844
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
a particularly aggressive checker, which is why it is off by default
Change-Id: Id5a0faa50b3ecc75e01f4aedc6579c5209e585da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idce9955294372817c0dd1f40ebd38f16fc90eab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91007
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8e942bf37c9173a01bef6e1403ca21f579e7f608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91612
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9cdd15185cfa8347a08402da956eab7cbdd63de6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91609
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I69c5b28636806e45d7ba5d8c4678caeda09caa50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4abf2df75c54936e02a8a3d8fa26f2b249e69780
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91606
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If50fcacc6710f582281d8030c97c39a5d2201390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5698862e5890d3208bc7012b0ce5b60520797c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91571
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|