Feature Request: Spaces after Parentheses

[vwegert]

Hello,

I'm frequently running into the following issue: When typing in opening parentheses "(" with "automatically close parentheses" turned on, the ABAP code editor automatically inserts a space after the opening parenthesis. This a sensible choice for method calls, but it's not helpful for character field length specifications or inline data declarations. I always end up typing DATA( foobar) and find myself navigating back to delete the unwanted space. If I turn off "automatically close parentheses", I get neither the space nor the closing parentesis. Would it be possible to de-couple the space and the closing parenthesis from each other in the settings?

Thanks

  Volker Wegert

[ThFiedler]

Hi Volker,

I just checked the behavior in my ADT client 2.60. When I enter DATA( in the editor I will not get a space. The space is only inserted for CALL METHOD REF->HUGO(

Which client version do you have?

Regards,

Thomas.

[vwegert]

Hi Thomas,

I'm using com.sap.adt.core.devedition.feature.group 2.60.4 - hope that's the version you meant. I've just rechecked after re-enabling the "close parentheses" setting:

• DATA( turns into DATA( |) (with | being the cursor)
• foo = bar( turns into foo = bar( |)
• foo->bar( turns into foo->bar( |) (which would be okay)
• METHODS foo RETURNING VALUE( strangely turns into METHODS foo RETURNING VALUE(|) - no space here, which is good.

Best regards

  Volker

[ThFiedler]

Hi Volker,

I'm a bit confused about which feature we are talking here. I mean that feature here:

And you?

Regards,

Thomas.

[vwegert]

Hi Thomas,

we're talking about exactly the same feature.

Best regards

  Volker

[dilorenzo]

Hi Thomas,

I would also be happy, if the automatic space could be turned off or even better only occur, when needed.

I would more likely enter a space where needed, then going back and delete the unwanted space.

Best regards,

Dominik

[schneidermic0]

Hi Volker,

I faced the same issue, yesterday. I defined an inline data declaration (i.e., DATA(<variable name>)) in a program in the very beginning of a source code line: The editor added a space between the brackets.

If there were some spaces in front of the DATA(<variable name>), the space would not be added.

We plan to provide a fix for this situation with the next version of our plug-ins. Could you provide further code snippets where it won’t work for you. We will try to reproduce and fix the issue also for these examples.

Thanks

Michael

[LukaszPegiel]

Hi Michael,

The same is when you want to use:

• message e001( )
• variable = variable+2( 6)

Cheers

Łukasz

[vwegert]

Hi Michael,

you are right, I never noticed that before: The problem with DATA(foo) only seems to appear if there is no whitespace at the very first position of the line. I get the same problem with VALUE() in a returning parameter if there is no whitespace before it in the line. However, as Łukasz mentioned, the problem also occurs at any other position in some cases (although I believe that's different and much harder to solve).

Best regards

  Volker

[schneidermic0]

Hi Volker,

Thanks, we have already fixed it for other keywords like VALUE(...), FIELD-SYMBOL(...), etc.

Kind regards,

Michael

[schneidermic0]

Hi Lukasz,

let's see whether we could improve the behaviour for the message statement.

Most probably, we won't be able to provide an improvement for the length access on variables, because we can't distinguish between a variable and a method, currently at the client. Accessing the ABAP server would take too much time.

Thanks for providing the examples,

Michael

[LukaszPegiel]

Hi Michael,

thanks.

Coming back to length acces, maybe it won't cover 100% of the cases but at least when you have "xxx+n(" then it's  on 99% lenght access. You won't have problem with methods in this case as there is no such syntax with methods.

What do you think?

Cheers

Łukasz

[schneidermic0]

Hi Łukasz,

Coming back to length acces, maybe it won't cover 100% of the cases but at least when you have "xxx+n(" then it's  on 99% lenght access. You won't have problem with methods in this case as there is no such syntax with methods.

This came also to my mind. I was just not sure whether developers would get confused if there are two different behaviours for length-accesses and offset-length-accesses.

Michael

[LukaszPegiel]

It would be half of the bug less