Wrong indentation with single-line case statements about verilog_systemverilog.vim

[lewis6991]

Its because the begin and end are on the same line. Is there any reason you are writing the case statement in this style? The begin and end's are redundant.

[xguerin]

Yes, it actually makes register mapping a bit more readable. Another type of issue arises when I skip begin and end:

case (XfrState)
  One_XFR : XfrState_str = "One";
  Two_XFR : XfrState_str = "Two";
  End_XFR : XfrState_str = "End";
  default : XfrState_str = "N/A";
endcase

is formatted :

case (XfrState)
  One_XFR : XfrState_str = "One";
  Two_XFR : XfrState_str = "Two";
  End_XFR : XfrState_str = "End";
default : XfrState_str = "N/A";
endcase

or, within a process:

always @(XfrState)
  case (XfrState)
    One_XFR : XfrState_str = "One";
    Two_XFR : XfrState_str = "Two";
    End_XFR : XfrState_str = "End";
default : XfrState_str = "N/A";
  endcase
end

[lewis6991]

I'm still not convinced about the begin statement(); end style. Im my opinion it should be avoided and discouraged. An older version of the new script did support this style, however I removed this at the benefit of better performance. In the future I will review whether adding this back effects performance and If it doesn't I'll change it back.

The other issue on the other hand was a different problem because the script wasn't reliably case-sensitive. I've just pushed a fix. Thanks for raising this.

[xguerin]

I don't mind adapting the code. Thanks for looking into it.

[vhda]

@lewis6991 I am unable to replicate the second situation in my current master branch. You did not include the case-sensitive fix in the PR, correct?

[lewis6991]

That is correct.

[lewis6991]

The reason you cannot replicate is because you probably don't have set ignorecase in your vimrc.

Having this set changes the behaviour of the plugin. My commit for this was to change this option and restore it at the end of indenting.

[vhda]

Understood. Let me think about this for some a day or two.

[lewis6991]

The only other solution I can think of is to have \C in every regex which I think would be a bit of a pain.

[vhda]

That's not the problem.

Try the exact same test case as above, but replace "End" with "end". I'm almost 100% sure that it will be incorrectly indented even with you case-insensitive fix.

We need to filter out strings. Maybe by doing something like we're doing for comments: we just strip them out from the input before parsing?

[vhda]

Just submitted some more changes. Please check them.

Could you take a look at the "end" issue for me? I can't invest more time in this for today :)

[lewis6991]

Stripping out strings may be the best solution. I'm just a little worried about performance.

[lewis6991]

Feel free to assign to me. I'll check it out when I get some time.

[vhda]

I was trying to!!! For some reason you don't appear in the list!

[lewis6991]

Is it because it is your personal repo and not an organisation?

[vhda]

Let me try this: @lewis6991

[vhda]

Dumb me: https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/

"You can only create assignments for yourself, collaborators on personal projects, or members of your organization with read permissions on the repository."

[lewis6991]

Fixed in 7d83a3e

[vhda]

Nice! Thanks.

[lewis6991]

Hope you don't mind me making commits like this without PR'ing them.

[vhda]

I don't mind, but I don't think that's the best workflow.

Now that I have a collaborator I'm considering starting to PR my own commits, giving us the opportunity to review and discuss the changes before submitting. Hopefully, this will result in better and more feature complete code.

[lewis6991]

I agree. I only pushed the commits today as I felt they were fairly trivial and small. I'll put future ones in a PR.

[vhda]

Will do the same.