-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[editor] Allow formatting only the selection #10204
base: master
Are you sure you want to change the base?
[editor] Allow formatting only the selection #10204
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a useful feature. I went over the code, it looks good to me (just left some nitpicks inline).
About Eclipse formatterSome things change unexpectedly, I use Eclipse. And apparently he took the "Arduino" formatter embedded in the settings, so he should obey the formatting ... I will be monitoring .. One thing that needs to be changed is the maximum number of characters to break the line, 80 is very little, I think it should be 120. I end up not using it because of this limit, which more hinders than helps. |
Hi @ricardojlrufino ! If I try to format this: I get this: doesn't look correct to me, I expect the indentation to be right. If I select the whole function (up to external |
Thanks, @cmaglie, for the feedback I had seen this problem, and I find it easier to correct using TAB to adjust the indentation. |
The purpose of this PR is to make things simpler: select a piece of source code and indent just that (this is to avoid the need to indent everything). IMHO it's a useful feature and a good idea, but adding comments to disable autoindent will make the whole experience very awkward, and completely defeat the usefulness of this PR. If there is no other way to obtain the right user experince I think we should just drop this PR. |
@cmaglie , this would be done programmatically and not by the user |
ahhhww, sorry I misunderstood, so your proposed algorithm is:
Looking it that way it may work, I'm a bit concerned about the "details", like what happen if I partially select a line? maybe we should indent the whole line even if partially selected. |
Did you also test this? Would be nice to have some actual unittests for this behaviour too. I think there's already one for formatting the entire source, could be added there (see the README for how to run unittests). |
|
||
// Remove format tags | ||
formattedText = formattedText.replaceAll(Pattern.quote(FORMAT_OFF), ""); | ||
formattedText = formattedText.replaceAll(Pattern.quote(FORMAT_ON), ""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems too general: If the code already contained these format off tags, they would now be removed. I would suggest to remember the offset where the tag was inserted (offset from the end for the third tag), and remove it only from there. As a sanity check, you could check that astyle has indeed left all text up to and including the second tag (and from the third tag to the end) indeed unmodified, otherwise your offsets would not be valid anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, i put keyword 'DYN' to allow this and not conflict with pre-existing format tags
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. I would still think this is somewhat fragile (a user might also put "DYN" in there), but I guess it works well enough in practice. On advantage of doing some offset calculations is that you can at the same time verify that nothing outside of the selection was changed.
formattedText = formattedText.replaceAll(Pattern.quote(FORMAT_ON), ""); | ||
|
||
textArea.setText(formattedText); | ||
textArea.select(selStart, selStart); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICS, this clears the selection and puts the cursor at the start? Might be good to keep the selection (requires recalculating the end of the selection, but that is probably easier if you solve my previous comment too).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will place the cursor at the beginning of the SELECTION. I would have to recalculate the positioning of the new format, to keep things simple and straightforward I decided not to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No negative point for usability
|
||
// Calculate offsets from begin and end of each line. | ||
int fristLineOffset = textArea.getLineStartOffset(lineStart); | ||
int lastLineOffset = textArea.getLineEndOffset(lineEnd); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this line offset stuff also work correctly when the selection boundaries are just before or just after the newline? Probably something to add a test for all four cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the example where I need to format 1 line only, and the cursor is at the beginning of the next line? It will force formatting on the 2 lines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, yes. I think I would expect that if I select no characters on the second line, just the newline separating both, I would only format the first line, not the second?
For the start of the selection, it's probably mirrored: If I select just the preceding newline and no characters on the previous line, I would expect to not format the previous line.
Hm. One other approach, in theory, is to format the entire file, and then replace everything outside of the selection with the original unformatted code. But since astyle might change the number of lines, it will be impossible to decide which old lines correspond to which new lines... Any idea what astyle does with unfinished code? E.g. if you pass code that starts at the start of the file, but then ends halfway a function, comment or expression? If astyle handles that properly (as far as possible), then you could:
Effectively, you'll be formatting everything up to the end of the selection and then undoing everything up to the start of the selection. I guess this can still break, especially if the selection start ends up halfway an expression (then the result of 1 might not be a prefix of the result of 2 because step 2 has more information and might layout code differently), but if you keep the "expand selection to entire lines" step you have now, I suspect that this might actually produce reasonable results (and if it breaks, it can be detected and an error shown). |
Hm, I would want to avoid that, since trying to parse source code is really tricky to get right (as can be seen by all the fallout of the autogenerated function prototypes...). Though I guess that just parsing comments can be done without understanding anything else of the code, and just for the formatting, it's ok if it is not entirely perfect... Good to see tests, they look good at first glance. |
In this case, not... see last commit.. |
Ah, that makes it a lot better indeed :-) |
All Submissions: