svx/source/svdraw/sdrundomanager.cxx |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit ef96de2252bca350a491185704de10b137a29ab3
Author:     Andrea Gelmini <[email protected]>
AuthorDate: Sat May 14 16:30:47 2022 +0200
Commit:     Julien Nabet <[email protected]>
CommitDate: Sat May 14 18:15:20 2022 +0200

    Fix typo
    
    Change-Id: If7581fbc808b985cbf6d81a2e66571ddc465f16e
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134320
    Tested-by: Jenkins
    Reviewed-by: Julien Nabet <[email protected]>

diff --git a/svx/source/svdraw/sdrundomanager.cxx 
b/svx/source/svdraw/sdrundomanager.cxx
index 2f286096c160..3d5fde475ac8 100644
--- a/svx/source/svdraw/sdrundomanager.cxx
+++ b/svx/source/svdraw/sdrundomanager.cxx
@@ -102,8 +102,8 @@ bool SdrUndoManager::Redo()
             // The problem here is that Undo/Redo actions historically 
reference
             // XShapes/SdrShapes by pointer/reference, e.g. deleting means: 
remove
             // from an SdrObjList and add to an Undo action. I is *not*
-            // adddress/incarnation-invariant in the sense to remember e.g. to
-            // remove the Nth object in tha list (that would work).
+            // address/incarnation-invariant in the sense to remember e.g. to
+            // remove the Nth object in the list (that would work).
 
             // It might be possible to solve/correct this better, but since 
it's
             // a rare corner case just avoid the possible crash when 
continuing Redos

Reply via email to