Rearranger: bug with Separator Comment's "%FS%" when using tabs

I have defined some separator comments which should end at position 80:

Comment separator text (using \n and \t for newline and tab characters):
\n
\t// Fields %FS%\n

Fill string: =
Fill width: 80

Placing the caret behind the last generated = shows 84 in the status line instead of the expected 80.

Tom

7 comments
Comment actions Permalink

Why this message does not occur in my news-reader (Thunderbird)?

0
Comment actions Permalink

Hi Thomas,

Thanks for the bug report. I will take a look.

-Dave

0
Comment actions Permalink

Tom,

The actual length of the string being generated is 83 characters. (The cursor position shows as "1" when the cursor precedes the first character on the line, hence, if the status line shows 84, then the cursor is positioned following 83 characters.) You wanted a line length of 80 characters.

The reason that Rearranger is emitting 83 characters is that the tab character occupies one space, but is expanded by the editor into 4 spaces when you view it. (Of course, tab spacing value can be changed by the user.) Rearranger stupidly counts the tab character as a single character, not realizing it becomes four in your document.

So the bug is that I am not counting tab characters correctly. Since tab characters can appear anywhere in the line, and expand to varying numbers of actual characters, I would need to expand the tab in place to determine the eventual (apparent) spacing.

There is a pretty simple workaround for this bug: replace your tab character "\t" in the comment separator text with four spaces.

Would you be willing to do that? I'm inclined to not try to fix this one, unless there's an extenuating reason. Perhaps you prefer to retain tabs (or just leading tabs) in your documents.

I was hoping to avoid becoming as smart as the editor in terms of retaining tabs (or emulating "smart tabs", whose behavior is not exactly clear to me from the IDEA documentation).

-Dave

0
Comment actions Permalink

Dave, thanks for taking a look into this problem.

There is a pretty simple workaround for this bug:
replace your tab character "\t" in the comment
separator text with four spaces.

Would you be willing to do that?


I've changed the "Fill Width" value to 76 as a work-around.

Perhaps you prefer to retain tabs (or just
leading tabs) in your documents.


Yes, I use smart tabs in my files, so my co-worker can see everything correctly aligned with 2 spaces-each-tab.

I was hoping to avoid becoming as smart as the editor
in terms of retaining tabs (or emulating "smart
tabs", whose behavior is not exactly clear to me from
the IDEA documentation).


There is no problem simulating the tab character expansion unless you know how much spaces a tab represents (for me 4 spaces). The "smart tab" feature does not influence this issue, but just ensures that leading tabs are only inserted for non-wrapped lines. For "smart tabs" wrapped lines (the wrapped part, not the leading) will be indented with tabs (the same count as the leading part of the wrapped Java line) and fills the rest with spaces.

--
Cheers,
Tom

0
Comment actions Permalink

Tom,

Pardon me, I'm a little confused. If you and your coworkers have different tab spacing settings, is there any value to leaving tabs in the filled comment strings? By doing so, the end position of the comment line will vary; in other words, it would not be a fixed width at all.

I can certainly get the tab spacing setting and do the calculations to make the comment line width come out correctly, but I am wondering if I ought to substitute spaces for tabs during that process so that the comment line remains at the specified width (regardless of subsequent changes in tab spacing settings).

-Dave

0
Comment actions Permalink

Dave, you are right. Only with tab-size set to 4, the comments end at column 80. But it's no problem for us that the comments end at column 78 when the tab-size is set to 2.

0
Comment actions Permalink

Tom,

Thanks for your patience. I've uploaded a new version (4.7) of the plugin which calculates the apparent width of a separator comment that contains leading tabs. Net result is that for your situation, with tab size set to 4 and one leading tab character, the comments will end at column 80. When your colleague views the rearranged file with a tab size set to 2, comments will end at column 78.

Embedded (non-leading) tabs would present a worse problem, especially if they occurred after or between %FS% expansion tags. I think they would have to be replaced with spaces before the expansion. Otherwise, the amount of expansion of a %FS% would cause the tabs to have different apparent widths. But let's not worry about this case -- you're not doing that. :) (Please? :) )

MBG
-Dave

0

Please sign in to leave a comment.