https://bugs.freedesktop.org/show_bug.cgi?id=58744
Priority: medium
Bug ID: 58744
Assignee: [email protected]
Summary: EDITING: Cannot search with paragraph breaks or
replace with line breaks; inconsistencies in search
expressions
Severity: normal
Classification: Unclassified
OS: Windows (All)
Reporter: [email protected]
Hardware: x86-64 (AMD64)
Status: UNCONFIRMED
Version: 4.0.0.0.beta1
Component: Writer
Product: LibreOffice
Forenote: had I the option, I would have picked 'design flaw' or 'annoyance'
for the severity, as this seems not to be an outright bug, but I wouldn't call
it an enhancement since this issue involves function people (at least I) would
expect present in the first place. If there is a better category, please file
accordingly.
Several of the inconsistencies in how search symbols and expressions are
defined in LibreOffice bug me to no end. Specifically, I find it quite annoying
that I am unable to search with paragraph breaks like I can any other
character, especially since
a. they are very common
b. they represent a significant part of text flow
c. Writer/LibreOffice imposes an absolute limit on how many characters may
exist in a paragraph
In addition, as someone who works in a language (Japanese) where line breaks
are also an important element, I also find it frustrating that (AFAIK) it is
impossible to replace search strings with a line break character.
Current behavior (with regular expressions enabled):
-Search for '$' selects paragraph break
-Search for '^$' selects 2nd of two consecutive paragraph breaks
-Search for search string preceded/followed by '^'/'$' selects search string
following/preceding paragraph break but not paragraph break itself
-Search for something followed by '^' or something preceded by '$' returns no
results
-Search for '\n' and replace with '\n' replaces line break with paragraph break
-The restriction on number of characters in a paragraph effectively makes the
'$' search string useless, as any attempt to replace '$' would simply replace
all paragraph breaks in the document with some other character, resulting in
unexpected behavior when the now one-paragraph-monster document exceeds the
paragraph limit (most documents are longer than the paragraph limit).
Note: In v4.6.3 or earlier, there were also some bugs where line breaks were
sometimes incompletely treated like paragraph breaks; e.g. at least some of the
above would (buggily) apply to line breaks as well as paragraph breaks. These
appear to have been fixed for the new beta.
In other words, the '^' and '$' symbols represent the beginning and end of a
paragraph, (cursor position immediately following and preceding a paragraph
break,) respectively. However, in the inconsistent cases of searches for '$' or
'^$', the '$' symbol is suddenly treated as the paragraph break symbol itself.
Furthermore, in the replace field, the same '$' symbol is then used with
numbers to represent parenthesized strings in the search field (e.g. '$0',
'$3'), and the '\n' sequence becomes the symbol used for a paragraph break,
leaving no symbol for line break in the replace field.
The ultimate result is multiple inconsistencies in what various symbols
represent, the inability to search for (and ergo replace) paragraph breaks in
(effectively) any but the empty paragraph ('^$') case, and the inability to
replace anything with a line break (it's search symbol, '\n', having been
usurped by the paragraph break in the replace field).
Following, I have prepared two alternate solutions to this mess: the first
being the most self-consistent and complete (and therefore the one I prefer) at
a moderate cost of consistency with previous versions. This would also seem the
easier to implement. The second, on the other hand, compromises
self-consistency and ease of implementation somewhat in favor of
version-consistency.
Proposal 1:
Of the '^' and '$' symbols, choose one (preferrably '$' as '^' also means not
in some cases) to represent the paragraph break character and return the other
to regular character status. In the replace field, inherit the search field
definitions: '^' or '$' for paragraph break, '\n' for line break, and a number
enclosed in parentheses to represent parenthesized search strings in the same
manner '$' followed by a number is currently used.
This scheme maintains all previous function; for example (assuming '$' for
paragraph break):
-Search '^something' Replace 'else' becomes Search '($)something' Replace
'(1)else'
-Search 'something$' Replace 'else' becomes Search 'something($)' Replace
'else(1)'
-Search 's.m.th.ng' Replace 'still $0' becomes Search 's.m.th.ng' Replace
'still (0)'
-Search '\)(parenthetext)\(' Replace '($1)' becomes Search '\)(parenthetext)\('
Replace '\((1)\)'
-Search '\n' Replace '\n' becomes Search '\n' Replace '$'
but at the same time enables functions like:
-Search 'linebreakgoeshere' Replace '\n'
-Search 'something$else' Replace 'something\nelse'
-Search '(else)$(something)' Replace '(2)$(1)'
-Search '(.)${4,}(.)' Replace '(1)$$$(2)'
This scheme is more intuitive because symbols are used self-consistently
(paragraph and line breaks are treated like other characters, and expressions
represent the same function in both search and replace fields) and consequently
reduces consultation with the help manual.
Proposal 2:
Should there be some valid and pressing reason the current configuration be
maintained as much as possible, the following changes can be implemented with
minimal change to current definitions, at a cost to
self-consistency/intuitiveness and ease of implementation:
Consistently recognize '^' and '$' as the cursor positions following and
preceding a line break, respectively, and '\n' as the line break character. In
the replace field, '$^' would represent the paragraph break character.
Changes to current definitions would be limited to those examples similar to:
-Search '\n' Replace '\n' becomes Search '\n' Replace '$^'
whereas the following new functions would become available:
-Search '$something' Replace 'something' (would remove paragraph break
preceding 'something', whereas Search '^something' would not)
-Search 'something$else' or 'something^else' or 'something$^else Replace
'something\nelse' (would replace paragraph break between 'something' and 'else'
with a line break)
-Search 'something^${2,}else' or 'something^{2,}$else' or 'something^{3,}else'
Replace 'something$^else' (would replace 2 or more consecutive paragraph breaks
between 'something' and 'else' with a single paragraph break)
-Search '(s.m.th.ng)^' Replace '$^$1' (would move 's.m.th.ng' from the end of
the paragraph to the beginning of the next)
-Search 's.m.th.ng$' Replace '$^$0' or '$^&'(would insert a paragraph break
before 's.m.th.ng' at the end of a paragraph)
-Search '(else)$(something)' Replace '$2$^$1' (would switch 'else' at the end
of a paragraph and 'something' at the beginning of the following paragraph)
In summary, this would effectively enable the same functions as Proposal 1
would, only in a manner more consistent with the search expression definitions
of previous versions, albeit considerably more convoluted.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
