About Eclipse formatter

Some 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.

image

Hi @ricardojlrufino !

If I try to format this:

image

I get this:

image

doesn't look correct to me, I expect the indentation to be right. If I select the whole function (up to external { }) then the indentation is correct. I think the context must be taken into account but don't know if this is easy to do with libAStyle

Thanks, @cmaglie, for the feedback
I did not analyze the library in depth, but looking over it I did not see this option.

I had seen this problem, and I find it easier to correct using TAB to adjust the indentation.
Trying to identify the context, and adjust it automatically, seems like it’s not that easy.

Hi, i found a hack: Add comments to disable the formatting..

Before

image

After:

image

In this case, you would have to insert these comments dynamically into the text ... and have them formatted, then remove ...
It seems a little ugly, but it was the way I found it

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.

but adding comments to disable autoindent will make the whole experience very awkward

@cmaglie , this would be done programmatically and not by the user

ahhhww, sorry I misunderstood, so your proposed algorithm is:

1. add indent-off tag at the beginning
2. wrap user selection between indent-on and indent-off tags
3. perform auto-indent
4. removed added indent-off and indent-on tags
5. redraw

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.
What if I select a real comment in the source code (how the // INDENT-ON will be inserted in the middle of a /* ... */ comment for example)?

I managed to implement.
The following tests were done, and they all worked as expected.

image

image

image

image

image

What if I select a real comment in the source code (how the // INDENT-ON will be inserted in the middle of a /* ... */ comment for example)?

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).

What if I select a real comment in the source code (how the // INDENT-ON will be inserted in the middle of a /* ... */ comment for example)?

NO WOKS ... =[

image

image

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:

1. Format the code before the selection. Save the both the original and the result, but do not apply it.
2. Format the code from the start of the file to the end of the selection.
3. Then, in the result of step 2, find the result of step 1 and replace it with the original of step 1.

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).

I tried your alternative and others, it is complicated to predict all cases.
I ended up finding a simpler solution, is to detect if it is in a comment, and take off until the beginning of it.

Fixed: prevent erros if cursor is in multi-line docs comments, like:
image

I also added new test cases for selection formatting

Stopping here, a lot of work for little gain ..

I ended up finding a simpler solution, is to detect if it is in a comment, and take off until the beginning of it.

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.

Hm, I would want to avoid that, since trying to parse source code is really tricky

In this case, not... see last commit..
RsyntaxTextArea provide a Token model.. making it much easier to know that the cursor is on top of a comment

RsyntaxTextArea provide a Token model.. making it much easier to know that the cursor is on top of a comment

Ah, that makes it a lot better indeed :-)

CLA assistant check
All committers have signed the CLA.