Being able to search for the end ($)
or the beginning(^)(\A)
of a paragraph is a common regex search criteria.
This patch adds the support needed to find the beginning.
It works for both forward and backward searches.
The problem is that the search code
generally assumes a non-zero-length match,
but of course the beginning position is exactly that.
So things get tricky trying not to skip anything
and yet still avoiding infinite loops.
So why doesn't it work in the first place?
-for Find Next: we do NOT want to do a bFirst search
because we are probably already there (both Point and Mark).
Otherwise it never gets past the first match.
For regular text, the Point is past the start of the match
(the Mark) so it doesn't find it twice.
-For Find All: on last node, can't forceMove, so infinite loop.
-bToNextPara force move handles the previous cases
-alternatively could be handled by tracking with a bForceMove
Wrap-around already works (want bFirst = true to test CurrPos).
Find-in-selection already works (want bFirst = true).
Find-All already works (want bFirst = true).
-all these MustStartWithCurrentNode
I was tempted to do something similar for FindAttr (tdf#129449).
make CppunitTest_sw_uiwriter7 \
CPPUNIT_TEST_NAME=testTdf147583_backwardSearch
Change-Id: I192b48d556e84f4f04c844ff65be03dc6c0c6707
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209094
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a 27.2 regression for
my commit fe185d43cc
It fixes the problem that Find Previous
wasn't finding attributes in earlier paragraphs.
At least, it wasn't finding non-hints (aka entire paragraph).
[easily seen with 'without strikethrough']
I missed that important aspect of the code which I cut from
sw/source/core/crsr/findfmt.cxx's FindFormatImpl.
oPam->GetPoint()->SetContent(bSrchForward ? 0 : rNd.Len());
Change-Id: Idc14dcc7921e8620794eb4fc2ff333317bef117b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209046
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Allow the user to find all of the text marked as hidden.
This only works if the hidden text is already visible.
Otherwise normal Writer calls just skip it
while walking through the text positions
and a 'not found' is returned.
So no 'privacy' or 'invisible selection' concerns.
Everything 'just works' as soon as the box is visible. Nice!
From sw/inc/hintids.hrc, we have
SvxCharReliefItem> RES_CHRATR_RELIEF(RES_CHRATR_BEGIN + 35);
SvxCharHiddenItem> RES_CHRATR_HIDDEN(RES_CHRATR_BEGIN + 36);
SvxOverlineItem> RES_CHRATR_OVERLINE(RES_CHRATR_BEGIN + 37);
SvxRsidItem> RES_CHRATR_RSID(RES_CHRATR_BEGIN + 38);
So instead of stopping at RELIEF and start/stopping at OVERLINE,
just stop at OVERLINE.
Change-Id: I81424127a2c9897b2c6cb404eaa613879f00cdc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208884
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The comments were created in commit 076f9e4883
Author: jp <jp@openoffice.org> on Wed Oct 31 14:55:46 2001
Bug #93764#: ExechSearch - return correct WhichId range
But those numbers seem completely pointless
and I don't recall seeing this kind of 'documentation' elsewhere
so it is not common, nor was it kept up by later additions.
I'm removing it because I want to eliminate
one of the numbered lines, and doing so will throw the numbers off.
So just get rid of them first, so I don't polute my change patch.
Change-Id: I628f18f975fa9ca91e6153e30f699fcfd7b6af54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208883
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The search dialog has the ability to open a paragraph format dialog.
That dialog has unit-dependent things like indents, spacing.
Ensure that sw module knows the user's preferred measurement unit.
Surely there is a better way to do this
than to assign it every time a dialog possibly starts...
Change-Id: I78bd0a2ad4a68b03b47bb87069e9d3c67b6f7fa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208871
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This reverts 27.2 commit 48c5a68879
tdf#129449 sw findcoll: find in empty first or last node
because it only affected this removed code block.
While it fixed the find-once scenario, it didn't fix find-all.
An earlier patch for tdf#172849
broke the 'FindAll count' for empty paragraphs
when it fixed empty-para-count for ReplaceAll.
That is because SwFindParaAttr::DoFind was guessing
that it ought to move immediately at the end of a paragraph.
But this far down in the process we don't have enough info
to know or guess whether we ought to move or not.
- in a selection - shouldn't move (start from start of selection)
- in a wrap around - shouldn't move (start from start of document)
- after an earlier find: => move (done earlier in this patchset)
- unless a text search: after para end searches anchored frames...
- for a find-once when the initial cursor starts at the end: => move!
make CppunitTest_sw_uiwriter7 CPPUNIT_TEST_NAME=testTdf131431
Apparently LOKit can also search editeng objects for text,
while the LibreOffice desktop doesn't seem to.
Pre-Moving is not necessary when text-search is involved,
so that is how I avoided that anchored-to-Len0-para problem with
make CppunitTest_sw_tiledrendering CPPUNIT_TEST_NAME=testSearch
I should have created another unit test
to check find-once starting at beginning or end.
However, SvxSearchItem knows nothing about the attribute set,
and XSearchable is UNO crap that doesn't provide anything useful.
and XReplaceable can only replaceAll, not replaceNext.
make CppunitTest_sw_uiwriter11 \
CPPUNIT_TEST_NAME=testTdf129449_findReplaceParaStyle3
Change-Id: I80558ae4f116cf1ba9ee2a4e53125c6445c1346e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208820
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Moves m_pWrtShell->GetCursor()->Normalize to before SwSearchOptions
aOpts is constructed to fix search key not found when a forward search
results in a unique find selection to the end of the document followed
by a backward search or when a backward search results in a unique find
selection to the start of the document followed by a forward search
search. Unique find selection meaning the document contains only one
match of the search key.
Why this works:
SwSearchOptions checks if the cursor is at the start of the document.
After a forward search, the point is at the end of the document, and the
mark is at the start of the word 'bug'.
So when we create SwSearchOptions for the next (backwards) search,
bDontWrap is set because the cursor is at the end of the document.
Next, the cursor is normalised, effectively starting it before 'bug'.
Because bDontWrap was set, the search doesn't go past the start of the
document - and thus reports 'not found'.
So by normalising BEFORE SwSearchOptions, the cursor is not considered
to be at the end of the document, and so wrapping is allowed.
Change-Id: I4dd9e70a19d8a50395fcc21f4661756336399c06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208268
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
This reverts 27.2 commit d63a0b60fb.
Although Page Style existed in Attributes, it never worked AFAICS.
Using the clues from 'Page Break' in tdf#158011
the key is to simply have an 'invalid' RES_PAGEDESC
in the sw ItemSet. Then ANY Page Style matches... Perfect!
'Attributes' is a find-only piece,
so the SfxToSwPageDescAttr in the two bReplace blocks
didn't need to be restored in the revert
(as well as some other miscellaneous bits).
Change-Id: I7578afae4272e56aafd091d5725ac1ff0390a231
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208503
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
And it works. I don't really understand why...
Somehow, because it is INVALID it accepts
either PageBefore or PageAfter,
anything at all that is contained in a RES_BREAK nWhich 104.
So as long as the paragraph has a non-default (SvxBreak::NONE)
RES_BREAK attribute , it matches. Perfect!
Change-Id: Iaf34798ff69eb2d632a5e4e07d040a6508e21069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208444
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
In the Quick Find or Find&Replace dialog, after a match is found,
then if some frame had the selection,
then the visible selection is changed to cover the match.
However, UnSelectFrame actually sets the cursor as it disengages.
Well, we don't care about that cursor change,
so just drop it and restore the match-selection.
Change-Id: If5d7968f4541954defeead39306be685c872a73e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208129
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
It made a bit of sense when it was first introduced in
commit bcd4abb87d
CommitDate: Wed Dec 5 15:44:36 2007 +0000
Resolve backreferences in regular expressions
At least then each command fit on an entire line.
But now it doesn't, so just remove the variable.
Change-Id: I97749b779c29992bbc615ab0730bf58489cbb121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208043
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
When the dialog is opened, the last searched for string
(from the session, not from stored config) was already restored.
However, no attempt was made to restore the last replace string.
Although it might feel a little dangerous to provide a restore value,
it isn't really dangerous, because the user has to hit the
replace button in order for it to do anything.
The bug report is worried about replacing with 'nothing' by accident,
so I guess the 'danger' goes both ways.
Personally, I would like having both last values restored
in case I accidentally closed the dialog
(or closed it to get it out of the way while I manually made changes
and then restarted it to continue my replace task).
Only Writer replaces the 'search' content with a user's selection.
In this case it seems very wise to clear the replacement string.
Change-Id: Id9f40c01724978a2e51f685a60b9e3e75c21135a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207901
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This is a followup to the earlier fix for LO 3.4-ish.
During Find & Replace, the very first replace
often has never even done a find yet (i.e. no selection).
If there is a user-selection already,
then we certainly don't want to replace that non-found selection,
so ensure that the selection is a 'found match' first.
This was fixed for 'text' replacement in 3.4,
but the same idea applies to paragraph styles.
If the entire document was selected, then Replace was resetting
every paragraph - not only the ones that matched the 'find' style.
make CppunitTest_sw_uiwriter11 \
CPPUNIT_TEST_NAME=testTdf36181_findReplaceParaStyle
Change-Id: I642780b722521a04bbfcad945e0e8673378b5210
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207576
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Page Style is not a 'on or off' kind of attribute.
In order to compare a Page Style, you need a name to match,
and the attribute dialog has no ability to specify a name.
Change-Id: Ifd7e85bd7e0cc80e2ee9fbda87520c60045364f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207619
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Move the check for an empty replacement string with replacement attributes from SwView::ExecSearch (case REPLACE) to SwView::Replace.
Change-Id: I24bcd485967230cae31e42197ebb7f5d40f8bf6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187774
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
by wrapping up OUStrings inside some type-safe wrappers
to make it obvious in the code what kind of name we
are dealing with.
The new classes are in sw/inc/names.hxx
Note that I spun the names for table formats out into
their own name class TableStyleName, becuase they
are weird. Most of the time they are UINames, but
not always.
Change-Id: Iaf320639fd1aae8ba0f99866ff206906544c42be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178839
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is what all the functions called from SwView::FUNC_Search return:
SwWrtShell::SearchAttr, SwWrtShell::SearchTempl, SwWrtShell::SearchPattern;
and all of them use SAL_MAX_INT32 to denote 'cancel' state.
Change-Id: Icec9c6b33ebfc856e4a67320f3442324db7459d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183324
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Makes the search independent of find and replace options.
* Adds a button to launch a dialog for match case, whole words only,
and similarity search options.
* Adds a button to launch the find and replace dialog.
* Makes the find entry control have visual feedback when there are no
matches.
* Adds a label at the bottom of panel that shows the number of matches.
Change-Id: I2cffcf86978773471bb86c5e5cf8b967c24efa7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168834
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Tested-by: Jenkins
When accessibility is enabled, Calc will add tens of thousands of
listeners.
We then spend a significant chunk of time creating SvCTLOptions objects
(attached to ImpEditEngine) and adding and removing those objects from
the related listener lists.
But the required information is already globally cached by the officecfg
module, so we can avoid that overhead and just fetch it directly from
officecfg.
Change-Id: I7ff55fd7c4926866eb7086812275ba8bd6e84c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152645
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Leave editengine and non-paragraph usages of SvxLRSpaceItem as-is for now.
Add new items RES_MARGIN_LEFT etc., order them so that paragraphs can
have 3 consecutive items RES_MARGIN_FIRSTLINE..RES_MARGIN_RIGHT and
non-paragraphs also have 2-4 consecutive items
RES_MARGIN_RIGHT..RES_MARGIN_LEFT (only the 3 paragraph ones are
actually used now).
The HTML import filter is particularly annoying because it parses CSS
stuff into SfxItemSets without knowing where the items will be applied,
so it can't know whether to create SvxLeftMarginItem or
SvxTextLeftMarginItem... the split items are created in ParseCSS1_*
functions and then converted later if necessary.
WW8 import has some weird code as well, SwWW8ImplReader::Read_LR()
creates 3 items and then something wants to set every item on its own
so SwWW8FltControlStack::SetAttrInDoc() turned out rather weird.
Convert the paragraph dialog to handle the split items (by mapping them
to SID_ATTR_PARA_FIRSTLINESPACE/SID_ATTR_PARA_LEFTSPACE/
SID_ATTR_PARA_RIGHTSPACE), but the SvxRuler looks a bit more confusing
so convert in sw shells for now and leave that for later (also unclear if
changing these slot items like SID_ATTR_PARA_LRSPACE breaks any ABIs?).
Change-Id: I40431821868fd3e1cceba121b5539ff9ae6befbc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147024
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
SfxViewFrame::Current() is a festering wound, these ones look like they
were safe anyway, so no need to backport. But with enough checked static
analysis will kick in to flag new unchecked ones.
Change-Id: I359d71bda2ad1f8f720fae1f87a13eae94bb763c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144244
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
to act as an extra check that we have the association of Item and
TypedWhichId annotations correct.
(*) requires that I add an upcasting constructor to TypedWhichId
(*) Make the field dialog stuff in writer use a new item id
FN_FIELD_DIALOG_DOC_PROPS instead of abusing the
existing SID_DOCINFO
Change-Id: Ica4aea930c80124609a063768c9af5a189df1c27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129098
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Make LOK_CALLBACK_TEXT_SELECTION, LOK_CALLBACK_TEXT_SELECTION_START,
LOK_CALLBACK_TEXT_SELECTION_END and LOK_CALLBACK_TEXT_VIEW_SELECTION
also use pull model, i.e. LO core will only set a flag and when
CallbackFlushHandler needs the actual data it'll use getLOKPayload().
This again avoids a large number of messages passed to
CallbackFlushHandler only for them to be sooner or later discarded.
Change-Id: Ia7528039be996a6e9e8491b4eba3f4133582fa56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124146
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Master document relies on the Navigator listing all the sub-documents.
However there is no connection between the currently selected section
(containing the sub-document) and the entry in the Navigator making it
very hard to see what file needs to be edited. This patch highlights
the corresponding item in the Navigator at the current cursor position
in the document.
Change-Id: Iee32d1db0e40e302bfff7a879d47a5632ce4ed43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122103
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
It normally gets emitted by SwSelPaintRects::Show(), called from
paiting, but Online uses tiled painting and so doesn't need normal
painting.
Change-Id: If276ce176f4e65b4efe3d053941b83917df2ae1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119382
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed
to explicitly use 'value' in WhichRangesContainer's ctor, or create an
instance for use in SfxItemSet ctor (svl::Items is already defined as
a template value of corresponding type).
Instead of
WhichRangesContainer Foo(svl::Items<1, 2>::value);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>{});
now use:
WhichRangesContainer Foo(svl::Items<1, 2>);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>);
Change-Id: I4681d952b6442732025e5a26768098878907a238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This allows to make sure we actually use sorted which ranges,
and then it's safe to call SfxItemSet::MergeRange when needed.
Also this change relaxes the previous requirement that ranges
must be separated by at least one; this allows to have adjacent
ranges, like in
RES_FRMATR_BEGIN, RES_FRMATR_END-1,
RES_GRFATR_BEGIN, RES_GRFATR_END-1,
where RES_FRMATR_END is equal to RES_GRFATR_BEGIN. Allowing this
makes possible to (1) self-document the ranges, so it's clear
which ranges are included; and (2) be safe in case when these
constants would change, so that the one merged range would not
unexpectedly contain everything inserted between RES_FRMATR_END
and RES_GRFATR_BEGIN.
Change-Id: Iaad0f099b85059b3aa318a347aa7fbd3f6d455c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116909
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andrea Gelmini