https://bugs.kde.org/show_bug.cgi?id=475921
--- Comment #3 from Igor Kushnir <igor...@gmail.com> --- (In reply to shlyonskikh.alexey from comment #2) > I think the most obvious solution that will work in every case is making a > separate plugin that passes --offset and --length to clang-format, then > replaces the whole file with the result. That's a great idea. clang-format is probably the most popular automatic formatting tool. I don't think many other tools support sorting includes. So a separate plugin for clang-format would be most useful. Furthermore, if other formatting tools support specifying offset and length, they can be supported by the new plugin as well. This would also allow to optimize clang-format-ting by passing the code to be formatted via the standard input and reading from standard output instead of formatting a temporary file (though in case KDevelop's temporary directory resides in a tmpfs, this optimization might not be significant). The plugin would also greatly decrease the probability of misformatting or refusing to format a block of code. After all, even the new implementation of extractFormattedTextFromContext() is crude and unsophisticated (doesn't go much further than matching parentheses). https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/52 proposed a clang-format plugin in 2019. That plugin's main feature is a UI to configure formatting options. Merging that plugin into KDevelop was rejected because of its dependence on the C++ API of LLVM/Clang. But that plugin could be distributed separately from KDevelop, like kdev-python and other language plugins are. However, this bug can be fixed by a simpler plugin that keeps using the clang-format executable, and therefore can be included in KDevelop by default. A merge request is welcome. > But if that's not an option, here is a rough idea for a new way to format > that should handle this case well enough: I like the separate plugin idea much more, but here are my thoughts on this approach: 1. Confusing with string literals is not much of a concern, because a formatter tool is highly unlikely to reorder include lines within a string literal. 2. The include-reordering validator could kick in only when extractFormattedTextFromContext() is about to refuse to format because of a fatal mismatch. It would search for the include lines around the mismatch spot. First parse the block of includes starting at the fatal-mismatch line in the smaller text fragment (prefix or unformatted text, not the whole formatted file). Put all the parsed include file names (but not '<' or '"', which could theoretically be replaced by a formatter tool too) into a std::vector and sort it. Then parse the number of includes equal to the computed std::vector's size starting at the fatal-mismatch line in the whole formatted file, put these includes into another std::vector and sort it too. Then compare the two vectors: if equal, continue regular non-include matching after the matched include blocks in formatted and unformatted texts. -- You are receiving this mail because: You are watching all bug changes.
