https://bugs.kde.org/show_bug.cgi?id=365437

Igor Kushnir <igor...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Version Fixed In|                            |5.13.231200
      Latest Commit|                            |https://invent.kde.org/kdev
                   |                            |elop/kdevelop/-/commit/0a0a
                   |                            |309f3f1f0b9d17dada2aa9e9b14
                   |                            |46990ff9d

--- Comment #14 from Igor Kushnir <igor...@gmail.com> ---
Git commit 0a0a309f3f1f0b9d17dada2aa9e9b1446990ff9d by Igor Kushnir.
Committed on 15/09/2023 at 10:25.
Pushed by igorkushnir into branch 'master'.

formattinghelpers: implement a more advanced algorithm

1TBS Artistic Style enables the add-braces option, which adds braces to
unbraced one-line conditional statements. When a user renames a
variable, each file that references this variable is reformatted by the
current formatter. KDevelop::extractFormattedTextFromContext() then
attempts to extract only the variable and the whitespace that surround
it from the formatted file. But this function's implementation does not
expect or handle an opening or closing brace inserted just before the
renamed variable (Bug 365437).

I have implemented an alternative workaround 3 years ago, which looked
for a non-whitespace character inserted at the left-context-text
boundary, and, if found, gave up formatting and returned unformatted
text from extractFormattedTextFromContext(). However, such a limited
workaround cannot address the much more difficult right context issue
described and tested in the parent commit.

The existing algorithm simply ignores fuzzy character changes hoping
that the result would come up correct. Usually it does. But in some
cases encountered by end users in practice, the unsophisticated
algorithm breaks code by inserting or removing an unmatched brace. As
formatters grow more sophisticated and insert/remove more non-whitespace
characters, the algorithm would cause issues more often.

The new algorithm tracks opening/closing brackets, double quotes and
comments to prevent breaking code. A long comment in the definition of
extractFormattedTextFromContext() describes the algorithm in more
detail. While not 100% reliable, I expect the new algorithm to make
practical formatting issues much more rare. As new bugs are discovered,
the more advanced algorithm can be adapted, as subsequent commits show.

At this commit the test added in the parent commit no longer fails.
FIXED-IN: 5.13.231200

M  +811  -49   kdevplatform/util/formattinghelpers.cpp
M  +6    -7    kdevplatform/util/formattinghelpers.h
M  +85   -0    kdevplatform/util/tests/test_formattinghelpers.cpp

https://invent.kde.org/kdevelop/kdevelop/-/commit/0a0a309f3f1f0b9d17dada2aa9e9b1446990ff9d

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to