Enhancement of auto add ...

[Zoupers]

Describe the bug

A clear and concise description of what the bug is.

An example of daily action might like I want to add new argument after arg2. As there is an empty line with ... in the next line, I think we should auto add ... to the new line when we type enter after arg2.

To Reproduce

1. Code Like Below

*** Keywords ***
Pass Arguments
    [Arguments]    @{args}
    FOR    ${arg}    IN    @{args}
        Log To Console    ${arg}
    END


*** Test Cases ***
Example
    Pass Arguments
    ...    arg1
    ...    arg2
    ...

2. Enter After arg2

Expected behavior

A clear and concise description of what you expected to happen.

As is in the describe.

Screenshots

If applicable, add screenshots to help explain your problem.

See Code.

Versions:

• OS: [e.g. Windows 10]
• Robot Framework Version: 3.2.2
• Robot Framework Language Server Version: 1.7.4
• Client Version: VSCode 1.74.2

Logs
No need.

[fabioz]

Agreed. I've just done the change and a 1.7.5 pre-release should be out shortly with the change. Please test it and let me know if it works well now.

[fabioz]

Actually, VSCode marketplace is having some kind of outage (microsoft/vscode-vsce#810) and I can't publish the pre-release.

If you're interested you can get the .vsix from https://github.com/robocorp/robotframework-lsp/actions/runs/3910261583 and install it manually as I don't know when they'll fix the outage.

[Serhiy1]

I just checked out the preview, excellent work. One thing I immediately noticed was you can over-indent when pressing enter on certain parts of the line.

Some keyword     ${foo}    ${bar}

If you press enter at the end of ${foo} that will cause an over-indentation if you do it at the beginning of ${bar} it works perfectly.

[Zoupers]

Suddenly, I remember that \s in regex means \t, and some other blank character. However, in robotframework we use \t or \s{2,} as space splitter(pipe splitter might be more complex and can be ignore for now).

I browsed 0e1767c and found there might be some problem if we use \t as space splitter.

Besides, I still want the user have the ability to modify the auto add rule in the settings. But might need some tricks.

[fabioz]

I'll have to thinker a bit more about those.

[fabioz]

@Zoupers can you post your actual expectations?

i.e.: in the case of
Keyword<\t>arg

would you expect that to become the following?

Keyword
...<\t>arg

[fabioz]

I did some more improvements on this for tabs and 2 spaces. Please check the latest pre-release and let me know how it fares for you.

[Zoupers]

Sorry, I have something else today that I cannot focus on it. I will try to give it a try tomorrow and make some testcase the day after tomorrow at the latest.

[Zoupers]

I've tried some cases yesterday, most of them works perfectly. While in some special cases of mixed indent, \t is treated as , I don't know if it follows your expections. But I think those people with mixed indent should notice.

Here are the testcases.

*** Keywords ***
Pass Arguments List
    [Arguments]    @{args}
    FOR    ${arg}    IN    @{args}
        Log To Console    ${arg}
    END

*** Test Cases ***
Test Add ... 1
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...    |	a
	...   

Test Add ... 1 Result After Enter
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...    
    ...	a
	...   

Test Add ... 2
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...   | 	a
	...   

Test Add ... 2 Result After Enter
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...   
    ...   	a
	...   

Test Add ... 3
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...  |  	a
	...   

Test Add ... 3 Result After Enter
    Pass Arguments List
    ...    arg1
    ...    arg2
    ...    arg2
    ...  
    ...   	a
	...   

Because of the \t and are looked the same, so please paste them in some editor that can see the difference.

[fabioz]

Well, mixed tabs and spaces is a no-no in general (and because onEnterRules doesn't have support for group capture: microsoft/vscode#17281, there's not much we can do anyways -- hopefully it'll be implemented at some point as it'd simplify the implementation quite a bit and make the mixed tabs/spaces support possible, but until then there's not much that the language server can do about such use cases).

[Serhiy1]

Found a slightly annoying behaviour; if you're breaking up an inline IF statement, then the plugin auto adds ...

Try converting

IF    "${GLOBAL_VAR}" == "val_1"    RETURN    ${VAR_1}    ELSE    RETURN    ${VAR_2}

to

IF    "${GLOBAL_VAR}" == "val_1" 
    RETURN    ${VAR_1}
ELSE
    RETURN    ${VAR_2}
END

[Serhiy1]

I have thought of another enhancement to this feature while using it, though it may be controversial. The plugin should delete any trailing ... if there are no characters after it.

This is useful because sometimes the plugin does add a trailing ... when it's not needed.

Some Keyword     ${var_1}    ${var_2}
...    ${some_other_var}
...     # This continuation was auto-added due to a space that was present after the breakpoint. 
        #  Pressing enter should delete that continuation 

[fabioz]

I have thought of another enhancement to this feature while using it, though it may be controversial. The plugin should delete any trailing ... if there are no characters after it.

This is useful because sometimes the plugin does add a trailing ... when it's not needed.

Some Keyword     ${var_1}    ${var_2}
...    ${some_other_var}
...     # This continuation was auto-added due to a space that was present after the breakpoint. 
        #  Pressing enter should delete that continuation 

I thought about this, but this just isn't possible the way that the VSCode configuration deals with that (it can just add content on a new line, not remove existing content).

So, unfortunately, right now you really need to delete it in this case... the other possibility would be not adding the ... when the line starts with ..., just when it's split (so, that case would happen less often).