In commit 93aa742ba3 which is
20 years ago 'cl' did a big change to get to SfxUndoManager
which is a needed abstraction for the formally Svx-based
Undo/Redo stuff.
Unfortunately SdrModel::SetUndoComment was *not* supported
and this was expressed as just doing a
OSL_FAIL("svx::SdrModel::SetUndoComment(), method not supported with application undo manager!" );
in SdrModel::SetUndoComment when SfxUndoManager was used.
But SetUndoComment *is* used in nine cases in
svdraw/svdedtv2.cxx. All of these execute some action and
create Undos for it. All nine Undos were without any Undo
text since then - over 20 years...
I stumbled over that when adding needed Diagram stuff to
UnGroupMarked().
I fix this with this commit. Creating that fix showed me
why 'cl' intentionally did not support that, but just
abandoning functionality is not a good choice.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Idde2fcecc85a9eee39b62d38ed7d71a8cfbd3288
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2486
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 5adf090261d705123074a0fa1c46119b2bf44bf3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206022
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
We have a very large nested/list action here, which means
that RemoveOldestUndoAction() cannot do anything, and we spin
in the loop in sw::UndoManager::AddUndoAction
So we need to break out of that loop in this situation, which
makes the delete almost instantaneous.
Change-Id: Ia2bd9c0fd00c6551e99ae09154ecf0f680b9fcea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182748
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Not sure about the real underlying issue here.
In debug mode, we hit this assert. Changing it from an assert to a "do decrement mnEmptyMark if it would become negative" seems to help.
Change-Id: Ie23a685552d2f8153b67e18f9c0203ecbaad0ede
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174905
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
moNeedsClearRedo is an implementation detail,
so there should not be public functions for it.
Plus, NeedsClearRedo can be called either against
the CurrentLevel stack or the TopLevel stack
(whatever that implies - there is no documentation...)
and since it is a delayed call that means that
multiple NeedsClearRedo attempts could be made,
theoretically against both stacks.
My initial implementation was "last one wins",
(which may very well prove to be the best one)
but whatever happens, it should be clearly intentional.
Based on my limited skill at code reading,
it sounds like CurrentLevel might be more of an implemention detail
or a temporary expansion of a ListUndoAction,
so I am guessing that any request for TopLevel clearing
should be given priority.
For Writer, it is always clearing the TopLevel stack
sw/source/core/undo/docundo.cxx: ClearRedo()
return SdrUndoManager::ImplClearRedo_NoLock(TopLevel);
Change-Id: I195aefb696599f018712135a2e015549d534791f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171984
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Justin Luth <jluth@mail.com>
I know NOTHING about the intricacies of Undo/Redo.
However, this is my feeble attempt to add some sanity to it.
It should not be the responsibility of the caller
to know when they are allowed to call ClearRedo.
This patch reverts commit 0cd000bb83
author Daniel Arato (NISZ) on Mon May 10 15:41:28 2021 +0200
tdf#141613 sw: avoid possible crash when undoing header creation
which was not a sufficient hack.
I hope this patch lays a better framework
to handle future similar issues.
vvv NAIVE OPTIMIST ALERT vvv
mbDoing was added with
commit 9cb53122e9
Author: Frank Schoenheit on Fri Oct 22 15:00:39 2010 +0200
undoapi: more I/SfxUndoManager changes
in preparation of new Undo API features
and has been untouched since then AFAICS,
and there was never any mechanism to change mbDoing.
In other words, it has been sitting there doing NOTHING.
So, I am taking it over and using it how I imagine it was intended,
and how it is documented.
Change-Id: I7aa355cc6458ac8ba34ddb9ee73fc850dcbca702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170793
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Previously we assumed that the action to be executed is always exactly
the top of the undo stack minus 1 element.
Extend this, so that in case an other view appends two or more elements
to the undo stack, we still find our undo action. Obviously only do this
if all those undo actions are independent from us.
This requires replacing the swap in svl/ with a move-out + move a range
down + move in construct.
Change-Id: Ic12d32d6eb5e77618d99eddb4fa096802f32d655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125076
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Specifically, we used to not allow out of order undo at all if the redo
list was non-empty. This relaxes that condition a bit. Out of order undo
is OK with a non-empty redo list, in case all undo actions in the redo
list are either
1) owned by the current view or
2) independent from the undo action to be executed
I.e. if view1 has lots of type undo actions and an view2 adds a
single type undo action on top of it, then allow view 1 to execute
multiple of its typing undo actions, not just a single one.
Change-Id: I2f5d9404a9994ed74b65233d2a315976c27b28b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125023
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Undoing out of order is dangerous by default, so limit this to a very
specific case as a start, that allows growing in follow-up commits.
For now, allow out of order undo if:
1) redo stack is empty
2) we're in LOK mode (different views represent different users)
3) we undo a single action (count is 1)
4) the top undo action doesn't belong to the current view
5) the top and the previous undo actions are independent
Which only requires that SwUndoInsert::UndoImpl() is independent for two
different paragraphs, which seems to be the case.
Independent undo actions opt in for this, currently the only such
allowed undo action is SwUndoInsert ("typing"), which adds characters to
a single text node. Even those are only considered independent if they
operate on different text nodes.
On the positive side, this allows out of order undo in the frequent case
where two users collaborate on a long document and they just type some
new content into the document at different paragraphs.
Change-Id: Ibb4551e8f7046b4947491b8bf751eaa0cbb2d060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124949
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Goes from more than 30s to less than 1s on my pc.
We were getting stuck inside the loop in sw::UndoManager::AddUndoAction,
because the RemoveOldestUndoAction was continually doing nothing because
it was hitting the
if ( IsInListAction()
{
assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a
not-yet-closed list action!");
return;
}
code.
Which means that there is some bug here, but I'm not sure what. We are
deep inside the delete logic at that point, and it doesn't seem
unreasonable to opportunistically delete some of the UNDO list at that
point.
So the real fix is just the conversion from a while loop to an if-check.
Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
accidentally left it this way when doing
commit 19e715973e
Date: Mon Oct 29 16:15:27 2018 +0200
loplugin:useuniqueptr in MarkedUndoAction
Change-Id: I250676df7af27f485c5d34281ef0da1e127eb24c
Reviewed-on: https://gerrit.libreoffice.org/62694
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
SfxUndoManager is the only implementation of the IUnderManager
"interface", and it lives in the same header.
Plus this way we can get rid of some covariant parameters,
which will make using std::unique_ptr easier.
Change-Id: I6661b9876b18da830bead78794d237886cd3c5c9
Reviewed-on: https://gerrit.libreoffice.org/57317
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I71e3b2c9b4c68183288f43999d242e95ae13584d
std::unary_function is deprecated since C++11 and removed in C++17
90% done with regexp magic.
removed obsolete <functional> includes.
The std::unary_function base class was used in 3 places:
* chart2/source/tools/DataSeriesHelper.cxx: lcl_MatchesRole
is used in a std::not1 function helper who uses the members
return_type and argument_type.
- replace deprecated std::not1 with a lambda
* chart2/source/tools/ModifyListenerHelper.cxx:
lcl_weakReferenceToSame used the argument_type member in the
operator() parameter.
- inline the parameter type.
* xmloff/source/chart/SchXMLExport.cxx: lcl_SequenceToMapElement
used result_type and argument_type in operator().
- inline the types
Also fix compile error with gcc about finding std::for_each.
Change-Id: I073673beb01410c3108e7d0346d9e7d6b9ad2e2f
Reviewed-on: https://gerrit.libreoffice.org/39358
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Xisco Fauli