Skip to content
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

Indenter. VBA Statement continuation lines aligned farther and farther to right #6215

Open
CoderRPM opened this issue Jun 4, 2024 · 2 comments
Labels
bug Identifies work items for known bugs

Comments

@CoderRPM
Copy link

CoderRPM commented Jun 4, 2024

Rubberduck version information

Version 2.5.9.6316
OS: Microsoft Windows NT 10.0.22631.0, x64
Host Product: Microsoft Office x64
Host Version: 16.0.17531.20152
Host Executable: EXCEL.EXE

Description
Problem when using indenter at any level (Proj, Mod, or Proc) on a statement with multiple continuation lines (terminated with space-underscore " _").

In SOME, BUT NOT ALL circumstances, a continuation line will be indented MUCH farther to the right than the preceding continuation line.

When this strangeness occurs for a statement with multiple continuation lines, each subsequent continuation line steps farther and farther to the right and eventually falls off the right side of the window. Scrolling right shows they are still there. Just out of the window.

Somewhat strangely, in at least one example, the last two continuation lines reverted left to the indent level of the first continuation line. (see attached Clip).

Indenter Settings
Indent alignment options:
I have "Align Continuations" checked.
Does not seem to matter if I check or un-check "Ignore Operators".

To Reproduce

  1. Create a REALLY LONG text string in something like an EXCEL MsgBox statement or assign this long text thing to a string variable.
  2. Then use suitably placed double quotes ("), ampersands (&), and the space-underscore line continuation indicator ( _) to break it into pieces sized to keep all of the pieces within the window,
  3. Use any method of convenience to invoke the indenter: Hot Key combination, or use the command bar RubberDuck dropdown.
  4. Use any choice of indenter scope: Project, Module, or Procedure.
  5. Inspect Code
  6. See error

Expected behavior
I would prefer to have indenter pick an indent distance for the FIRST continuation line of a statement based on the rules selected by the currently specified Indent Options.

I would like subsequent continuation lines for the statement to generally align at that same indent distance.

Screenshots
image

Logfile
I will generate a trace log if you think it would be useful.

@CoderRPM CoderRPM added the bug Identifies work items for known bugs label Jun 4, 2024
@awb95
Copy link
Contributor

awb95 commented Jul 4, 2024

Looks like the indenter gets confused on line continuations of strings on lines with double qutes and komma.

I created some tests cases

Sub Tests()
    MsgBox "Fails," _
           & "With ""Qutes"", and Comma" _
                             & vbCrLf
    MsgBox "Fails," _
           & "With """"many Qutes"", "", and Comma" & _
                                        vbCrLf
    MsgBox "Fails," _
           & "With ""Qutes"" and, late Comma" _
                                 & vbCrLf

    ' Some working cases
    MsgBox "Works," _
           & "With """"many Qutes"""", and Comma" _
           & vbCrLf

    MsgBox "Works," _
           & "With ""Qutes"" and no Comma" _
           & vbCrLf

    MsgBox "Works," _
           & "Without Quotes, and Komma" _
           & vbCrLf
           
    MsgBox "Works," _
           & "Without Komma, and ""Quotes""" _
           & vbCrLf
           
    MsgBox "", "", _
           "Works" _
           & vbCrLf
End Sub

@retailcoder
Copy link
Member

retailcoder commented Jul 4, 2024

Thanks for the additional information and test cases! The 2.x indenter is essentially a (refactored to death / beyond recognition) port of the original Smart Indenter VB6 source code, which basically treats code as strings... which makes it limited in such edge cases. Makes me wonder how/whether the original indenter even deals with these (we've already patched quite a few holes from the original code)...
Anyway the 3.x indenter is slated to become a "format code" command that is going to work off hierarchical symbol trees, which don't get confused with line continuations and escaped quotes; solving it in 2.x is probably not impossible, but working with strings makes it much harder than it should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Identifies work items for known bugs
Projects
None yet
Development

No branches or pull requests

3 participants