Comment wrapping goofy?

[JSacharuk]

Forums! Great! Now I can run this past other people before filing a bug report.

Anyway, I've got comment block wrapping on -- I was hoping for something reasonably emacs-like, but I'm having problems.

I have the comment width set to Fixed Width 64, Max right column 80.

The problem is that SE isn't doing a good job wrapping to the longest line in the comment block, or wrapping after 64 characters. It seems to pick almost arbitrary lines to base the line wrap on. Take this comment that I've got half-done:

//-----------------------------------------------------------
//  AThingy::physDoodle
//-----------------------------------------------------------
/**
 *
 * @param deltaTime
 * @param Iterations
 *
 *  Implements
 *  doodle physics state for the thingy.

    @author Jan Sacharuk
    @date 07/Aug/2006

    @note JS -- This is
    all

*/

Admittedly, I think part of the problem is that part of this comment existed before, and I copied and pasted into it.

If I create the comment fresh, the lines extend for a longer time, but then don't wrap at 80 characters like they're supposed to. Basically, they seem to be pretty non-deterministic. I never know what I'm going to get. Sometimes when I hit return after a single line comment, it adds the // to the next line. Other times, it doesn't. I just tried it now with my cursor placed immediately below a // comment, and it added TWO lines of //.

Has anyone else had these weird problems?

[ScottW, VP of Dev]

I wouldn't be surprised if you have found some cases where the comment wrap is behaving in a flaky manner. We're working to identify those cases and fix them. What really helps is if you have a repeatable case that you can send us. Send us the file, or the the comment and indicate the cursor location. Provide a description of what you type and then what happens. It's best to send this to support@slickedit.com and they will file a defect.

Select Tools > Options > File Extension Setup and then pick the Comment Wrap tab. Do you have a check in "Preserve width on existing comments"? If so, SlickEdit will look for the longest multiline paragraph and use that as the width of the comment in an effort to match the formatting of the existing comment. In the sample you posted, that line is "doodle physics state...". This setting will override the values you have chosen for width. This setting has no effect if you are typing in a new comment. However, if you move the cursor away and then back to the comment, it will be treated as an existing comment.

If "Preserve width..." is not check, SlickEdit will use the values you specified in Fixed Width. It sounds like you are using the default values. Did you put a check in "Maximum right column"? If not, the value of 80 will have no effect and comments will be constrained to be 64 characters wide as measured from the leftmost, non-whitespace character in the comment. If "Maximum right column" is checked, then comments will be 64 characters wide as long as they do not exceed the column specified, which is 80 in your case. Comments will be wrapped at the column specified regardless of the width setting.

Hopefully this will help you better understand the behavior of this feature. If you are seeing it do something else, please send us the requested info along with the details from Help > About SlickEdit and we will work to correct those problems. Thanks!

--Scott

[Dswag89]

I have run into something goofy as well.  I just modified the filecomment and function comment aliases in alias.slk (see attached) and then started testing them out.  When I put a long "purpose" in the filecomment dialog box, it does not get wrapped properly.  Not even "Document... Reflow comment" will make it properly reflow.  I can start new comments in the file or add a function comment and they will wrap properly... but my original "filecomment" alias is messed up.

Another oddity with comments.  Given this comment:

/*
** this is a comment
*/

If you mess around, put the cursor at the end of the 2nd line and hit <delete> it looks like this:

/*
** this is a comment*/

Then hit <enter>, and it looks like this:

/*
** this is a comment
   */

Hit <backspace> 4 times to get rid of the 3 spaces and the <LF>, it looks like this again:

/*
** this is a comment*/

Hit <enter> and it looks like this:

/*
** this is a comment**
*/

The odd things are:
1.  When you "delete then enter", it puts in the 3 spaces.
2.  When you "backspace then enter", it puts two asterisks at the end of the previous line.

I'm going to post this message to "support@slickedit.com" as well, just wanted to get it on the forums here to see if anyone else has seen something similar.

Despite these oddities, I'm loving SlickEdit 11!

Dan

[ScottW, VP of Dev]

I can't replicate any of the problems you described. I don't doubt that they are happening, though, because I have seen similar behavior in the past. When you contact product support, please be sure to include the language you are using, your indentation settings (tab, spaces, etc.), and the values you have set on Document > Comment Setup. Please send in the values for the modified aliases so we can figure out why those are not being reformatted as well.

We'll see if we can reproduce these problems and fix them. In the meantime, Comment Wrap works best if you don't mess with the first and last line. Use those just for the comment begin and end characters. Also, don't put borders around comments. We've tried to preserve box style comments and the code for that is what is likely introducing extra asterisks on the right.

When this feature works, it takes so much pain out of writing comments. I've been wanting something like this for ages. Thanks for helping us knock out some of the rough spots.

--Scott

[JSacharuk]

I'm going to post the things that I THINK I've discovered so other people can test and compare to see if they're having these problems too, so we can pin down EXACTLY what's causing these problems. Testing and fixing is a lot easier when the reproduction steps are verified.

So, if I use Javadoc style comments at the BOTTOM of a file, I find the wrapping breaks.

Argh. Nope. I can't reproduce now, after doing it three or four times.

Here's something that I think I CAN verify, though. Any Javadoc/DOxygen style tags starting with the '@' won't break. Comments that follow will align themselves to the length of those tags. So, if you happen to have a 64-character name, your comments will probably look perfect.

The comment MUST auto-generate some information (I think ) for it to break.

So, can anyone help pin it down better than that? If not, I'll submit this bug as-is, but I hate giving such vague details. This is really just a description of what's broken, rather than what did it.

[hs2]

I know what you mean JSacharuk.
I also stumbled into a few annoyances while commenting, but unfortunately while 'meeting the deadline'...
So I'd no time to track them down to facts
Mostly I did it somehow or quickly switched off the comment-wrapping support.

Thanks to ScottW [thumb-up] explanations things getting clearer and some of the annoyances are solved by proper configuration now.
Anyway, I hope that I don't have to know too much constraints to use this feature in a controlled manner.

Ok - currently there is one major issue for me.
Comment auto-wrap should be limited to the current 'comment-paragraph' inside a whole comment block.
I'll try an explanation:
There is a java-doc block already containing some keywords (@parameter lines etc.) and blank (comment) lines.
I quickly want to edit e.g. the 1st @parameter description (only 1 line) and e.g. a <DEL> triggers a re-wrap...
The complete java-doc block is affected w/o taking into account follow-up keywords (next @parameter) or blank lines !
You'll find e.g. the next @parameter just somewhere at the mentioned 1st @parameter line.
This is no good and in my opinion it also doesn't make sense.
So my proposal is to stop the re-wrapper at the end of the current 'comment-paragraph', which is the block related to the current @<keyword> or when the next comment-line is blank (and leaving it as it is - just blank).
This should be ok for those who like blank lines to separate things in comment blocks (as me) and the others hating blank lines are not affected.
In addition the latter should also be used for normal (non java/xmldoc) comment blocks.

Besides that using the javadoc-editor would solve a lot of my little problems. It's an extremely cool feature !
But often I do some on-the-fly comment editing/typo fixing w/o launching an extra tool.

Puh, that's enough for now. I've to hurry up to meet my next deadline

HS2

[ScottW, VP of Dev]

Comment wrapping was designed to work as HS2 described. Wrapping is constrained to a paragraph. Paragraphs are separated by blank lines, items beginning with @, and various HTML tags. Editing within any paragraph should not cause line wrapping to ripple to any other paragraph. Further, there should be no difference between auto-generated content and content you type. There are no special characters being inserted to give the comment wrapping code special directions.

I tried to reproduce the problems described by HS2 on both 11.0 and 11.0.1 and cannot. Here is a sample comment. Normally, my comments are more meaningful but I run out of things to type when I'm testing.

Code: [Select]


    /**
     * this si a sdlkfjsd sdljs dljkfsd lfjksd lfkjsd flkjsd
     * flksdjflksjd flksd lflsdkfj fksdj fd fdkfd fkd kfjsdlkfjd
     * kfsjdl fkjsdl fkjsd
     *
     * @author sdlkfjsd ldkj dlf dlfldj fkldj dlkfj dlkfkd sdlkfdjl
     *         fkdj ldskjf dlfksd lfkjd fljksd lfksd lfksdj flkdj
     *         fdkjd sdkjf dlskf fjsd lfkjsd lfkjsd lfkj sdlfk sdlfk
     *         sjdlfk sdjlfk s
     * @example sd dslkjsd lsdkj dl kjsd dslksd jlsdkj dslksd lkjd
     *          fldkj fslkfj dlfkjsd flkdj sdlf sdlf sdlfksdlf sdl
     *
     * @see dl;sfkj sdl sjkkj sdlfkj sdlfkj sdlkfj sdlfkj sdlfkj
     *      sdlfk jsdlfk sjdlfkj sldfk sl
     *
     * dsjf djkf sldkfj sdlfjksdl fkj sdlfkj sdlfkjsd lkfj sdlfkjsl
     * fkjs dlfkjsddk sdkl dlk dlk dkjf s sdsdjfw sldkf sdlfk sdlfk
     * sdlfks dlfk sdlfks dlfk sdlfk sdlfk sdlfks dlfks dlf sdlf s
     */


This comment contains 5 paragraphs. Editing the contents of any of these causes no alterations in the others. I can position my cursor within any paragraph and add new characters, use backspace to remove characters or press delete to remove characters. The only time another paragraph is alterered is if I press delete after the last character in a paragraph, which causes the subsequent paragraph to become part of the current paragraph--as you would expect.

I have tried this with a variety of settings. My last test was with Fixed Width 64, No maximum right column, Preserve width on existing comments is on, Enable block comment wrap is on, Enable Javadoc wrap is on, Use hanging indent on block tag comments is on. I did my testing in a Java file.

Please keep posting any problems you come up with so we can try to isolate what's going on. It would help if you could post a sample comment that I can then use to try to reproduce the error along with a quick summary of your settings or a screen shot of the Comment Wrap tab on Extension Options if you prefer.

--Scott

[hs2]

Thanks ScottW !
I imm. copy'n pasted of your (healing ?) example and - REALLY - it worked as described by both of us 
Amazing - I also tried to reproduce the issue described before at various places in my curr. (C-)project - no way !
Everything is just as great as expected from Slick.

Ok - for the time being just forget about my lengthy but obviously pointless post.
But stay tuned, I'm sure there is still s.th. to complain about

HS2

[Dswag89]

I'm working this from 2 angles, but maybe another community member can try it out.  Attached is a simple C file that I can't get the comment to reflow in the "file header".  If you open it and "Document... Reflow", what happens?  I'm trying to reflow it with "Fixed Right Margin" set at 75 and reflowing either the 'current paragraph' or 'entire block comment'.  The smaller blocks below it reflow fine, but not the "file header".

[Dswag89]

Still more goofiness, this one I can reproduce without fail.  Working in the C file attached in my last post, I can go to a new line and start typing.

1.  I type "/*" and the screen looks like this:
/**/
2.  I type <enter> and the screen looks like this
/*
**
*/
which matches my comment style perfectly.
3.  Since I'm not yet used to SlickEdit doing all of the comment helping, I'm already starting to type my "**" for the second line.  So, when I type the first '*', the line looks like this:

/*                                                                         
***                                                                      **
*/

From here on within this comment, it thinks I'm trying a "border" on the comment and puts the two '*' at the end of every line.  It wraps beautifully, but puts the end of line asterisks on there.

Can anyone recreate this one as well?

[hs2]

The latter issue is easy to 'solve by configuration':
@see Tools->Options->File Extension Setup->Comments Tab
There you can specify your way of doing block comments
In your case you've set a '*' in the (middle) Right field, which causes the surprising '*' at the right side.
I assume your the reflow issue is caused by a similar thing.

Good luck,

HS2

[Dswag89]

Nope, not the case. My comment tab setup is in an attached Word Doc. 

Dan

[hs2]

No way - works perfectly here.  (here: Slick v11.01)
But wait ... check THIS:
Click into the mentioned 'Right' field press HOME and hold down the DEL key for a while.
I'm sure you'll see a '*' after a while.
For some edit fields you can't see what's behind the wall - nasty...

Hope it works,

HS2

[Dswag89]

No deal, didn't work.  I'm using 11.0.0, because I'm worried about 11.0.1 (given other posts I've seen around here).  I even went so far as to "shift+ctrl+end" and "delete" to make sure it was all gone.  I've got two different comments working two different ways *IN THE SAME FILE*!!! Very odd!

[ScottW, VP of Dev]

Thanks for the updated info.

Dswag89, I used your sample foo2.c and I can easily reproduce the problem. The issue appears to be that there is no blank line between the header comment and the small filename comment just above it. Certainly, this is a defect and we will correct it. In the meantime, leave a blank line if possible.

Unfortunately, I wasn't able to reproduce the other problem you reported with the extra asterisks on the right hand side. I tried using v11.0 and v11.0.1 and both worked fine with the same settings you reported. This is an issue we hit in testing and one we put a fix in for in v11.0.1, so you should be sure to upgrade to that version. Do let me know if you are still seeing this in v11.0.1. I have no idea why I can't reproduce this problem.  Argh! 

Hmmm, maybe I'm just better at typing comments or something.

--Scott