Author Topic: Word Wrap and colon request,  (Read 8085 times)

greggman

  • Senior Community Member
  • Posts: 280
  • Hero Points: 14
Word Wrap and colon request,
« on: June 24, 2008, 12:44:34 AM »
Maybe there is a setting that already does this or maybe you can tell me how to hack slickedit to make this happen but.

With comment word wrap on if I have some code like this

Code: [Select]
// This is some comment I want word wrapped
// if the lines get too long but the lines below
// this I don't want wrapped.
// Parameters:
//   name: name of object
// Returns:
//   true if successful

Here's the issue. If I press delete anywhere in the 3rd line the 4th line, "Paramaters:", gets sucked up into the 3rd line.

I've been wondering if the word wrapping code could have the option to look on the line below and if there is a colon, don't suck up the line. That's my first thought so maybe there is a more robust check than just colon but I suspect, more often then not that is what I would want to happen.

Thanks for listening.

-gregg


Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Word Wrap and colon request,
« Reply #1 on: June 24, 2008, 11:22:02 AM »
Yeah, I have this problem too, but not just in doc comments and not just with delete.  I created a macro (as below) that I have bound to a function key so that I can turn comment wrap on/off quickly and see what the current setting is.  Usually I forget I have comment wrap on and find that comments I don't want reformatted get "sucked up" so I swear, hit ctrl z and then turn comment wrap off.

A possible solution for you is to have a blank line before the "parameter" line.  I suspect it would be hard for slick to determine when comment wrap should wrap and when it shouldn't  - maybe it could check for lines that don't look like they have been comment wrapped.  I vaguely remember also sometimes having problems getting slick to wrap a bunch of unwrapped stuff that I wanted wrapped.

Graeme


Code: [Select]
_command void my_comment_wrap_toggle() name_info(',')
{
   comment_wrap_toggle();
   if (_GetCommentWrapFlags(CW_ENABLE_COMMENT_WRAP))
      message('comment wrap on');
   else
      message('comment wrap off');
}

greggman

  • Senior Community Member
  • Posts: 280
  • Hero Points: 14
Re: Word Wrap and colon request,
« Reply #2 on: June 24, 2008, 02:47:11 PM »
Thanks for the suggestions but turn it on/off is not really a useful option for me and although if it was up to me I'd put a blank line, it's not up to me. My company's coding standards require that I don't put a blank line.

I really don't see why slickedit would have a problem. First off I'm asking for it to be an option, not the default so people that like the way it is would not have any problems. I know that in my case, the odds of their being a colon in a line I want word wrapped are next to zero. In fact, the odds of any puctuation except period, comma and underscore being in a line I want word wrapped a pretty close to zero.

It's just as annoying with the current system to type a code example in the comments.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Word Wrap and colon request,
« Reply #3 on: June 24, 2008, 05:22:46 PM »
You could take a look at macros\commentformat.e and tweak the logic in there (after a bit of reading to suss out how it works) to avoid wrapping those kinds of lines.  I've made a few changes in commentformat.e myself.

Note:  changing built in macro files can be hazardous; tread with care...

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Word Wrap and colon request,
« Reply #4 on: June 24, 2008, 09:29:31 PM »
Let me talk with the developer on this one. Certainly we could implement what you have asked, but would that be generally useful to all/most users? I'd like to find some more generic configurable approach that allows us to specify patterns that denote the end or beginning of a new paragraph.

We'll see what we can come up with.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Word Wrap and colon request,
« Reply #5 on: June 25, 2008, 01:11:04 AM »
Thanks, Scott, that would be excellent!

Or an additional approach (more flexible for someone willing to write a macro) would be to allow a way to specify a function to call.  E.g. commentformat.e could look it up with find_index(), and the function could return boolean whether to wrap.

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Word Wrap and colon request,
« Reply #6 on: June 25, 2008, 05:11:59 AM »
Let me talk with the developer on this one. Certainly we could implement what you have asked, but would that be generally useful to all/most users? I'd like to find some more generic configurable approach that allows us to specify patterns that denote the end or beginning of a new paragraph.

We'll see what we can come up with.

That'd be great...  as long as one of the patterns you can specify is that any line that is shorter than it would be if it were wrapped is considered the start of a new paragraph, just as a blank line or a line containing only a "bullet" or doc comment decoration is not wrapped when you type or delete on a line immediately before it.

Graeme

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Word Wrap and colon request,
« Reply #7 on: June 25, 2008, 02:10:39 PM »
Sorry, Graeme, but that won't work. The last line of a paragraph is almost always shorter than it would be if it weren't the last line. So that would prevent wrapping from working in this boundary case. Look at most of the paragraphs in this thread.

No, I think it has to involve some kind of pattern that the user can specify. Perhaps a list of regular expresssions that denote things that begin a new paragraph. In the original case sited, greggman says that he wants colons in the line to be used for that purpose. That would be an easy regex to write. My biggest concern with this approach is that a badly written regular expression can cause performance issues or very strange results. So, I'm concerned that extending the feature like this will cause a burden for support.

Is this where I get to insert my rant about overly specific coding standards that don't make the code any more readable and much harder for tools to support? There is such an easy workaround here if the judicious use of whitespace could be applied. But that would take all of the challenge out of this one.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Word Wrap and colon request,
« Reply #8 on: June 25, 2008, 07:03:06 PM »
There are other scenarios to not wrap, too, it's not just about headings (which personally I would put a blank line above to make it more readable).  For example suppose there is a bulleted list -- SE natively support certain kinds of bullet characters, so a team might be convinced to use supported bullet characters.  Another example is a numbered list.  Or a table of changelog entries (each line containing date, name, comment).  Or another scenario (handled in a different place in the SE code) is certain HTML tags in a javadoc comment -- I've tweaked the SE macros to add a few tags that I don't want SE to wrap (such as <li><ul><ol></ul></ol><p>
 and a few others -- maybe some were already supported, but most weren't).

Another approach might be to have a number of canned regexs that can be selected, and the SlickTeam can test the expressions and make sure they perform well.

Or if you're worried about support calls due to bad perf you could add a lightweight timing measurement around the custom regex evaluations and pop up a warning (perhaps with a "Don't show me this again") if the evaluations take more than a few milliseconds.

Just a few thoughts off the top of my head, they may be half-baked.

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Word Wrap and colon request,
« Reply #9 on: June 26, 2008, 09:35:49 AM »
Quote
Sorry, Graeme, but that won't work. The last line of a paragraph is almost always shorter than it would be if it weren't the last line. So that would prevent wrapping from working in this boundary case. Look at most of the paragraphs in this thread.

Yep, but there was an implied part (in italics) to what I said.
"any line that is shorter than it would be if it were wrapped is considered the start of a new paragraph, and there is something to wrap to it."

i.e. there are probably no lines in this thread (except I've just created some) that are shorter than they would be if they were wrapped because there is nothing to wrap to them

But of course, as you say, the boundary case is the problem.  Still, slick could do better than it currently does in some cases.  For example with
word1
word2
word3

Press delete or paste something at the end of line 1 and slick adds word2 and word3 to the end of line 1 (depending on your settings).

What I would like slick to do is when the cursor first moves into a comment region, to determine and remember the start and end of the current "wrap region" by inspecting the length of the lines. e.g. if I move the cursor onto word1 above, then line1 is the start and end of the current wrap region.  If I start typing more text at the end of line one, slick doesn't wrap word2 to the end of what I'm typing because it was not part of the current wrap region that was determined when I first moved the cursor onto line one.

That would take care of a lot of cases, and many times it would take care of the problem originally posted in this thread.  The case that it doesn't take care of is when the line preceding the shorter line (the boundary case that you mentioned) is "full length" because there's no way to tell if the last line should be part of the preceding wrap region or not.  Or more generally, suppose I want to have a line that is never wrapped (before or after) e.g.
<a few wrapped lines 1>
Don't wrap this line please.
<a few more wrapped lines 2>

One possibility to take care of this is for slick to notice that the "Don't wrap this line please." line is shorter than it would be if it were wrapped and determine that it's not part of wrap region "lines 1" nor "lines 2".  To handle the case of the "Don't wrap this line please" line or the preceding line being full length, the only way to do it is to have a special character sequence somewhere to denote a non-wrapped line or to denote the start or end of a wrapped region  e.g. any line ending in # or /nw isn't wrapped (or containing a colon as the OP asked, or matching regex as already said).  This would also allow you to have a line longer than the wrap limit if you wanted.  As long as everything is configurable, that's the best you can do for this case. 

I would put this extra capability under an umbrella of "intelligent comment wrapping" that you could turn on and off on the fly, just as you can turn comment wrap on/off. 

Also an option to have the current status of comment wrap shown on the status line would be useful.

As I think someone else mentioned, it would be nice for slick to not do any wrapping in commented code.

Graeme
« Last Edit: June 26, 2008, 09:54:08 AM by Graeme »

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Word Wrap and colon request,
« Reply #10 on: June 26, 2008, 07:26:27 PM »
Thanks, Graeme, that makes it much clearer. The proposal does rely on the assumption that the comments are already consistently well formatted, but it should reduce the number of times the wrong result is produced. I am concerned about the amount of processing that is necessary before we can determine what to do, though. This functionality must not delay your ability to type.

Good suggestions, chrisant. I think we discussed most of those, and I thought more of those ideas were already implemented. I'll have to talk to the developer about that.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Word Wrap and colon request,
« Reply #11 on: June 26, 2008, 07:57:51 PM »
I forgot to talk about the commented code suggestion. We've certainly discussed this, but it's not a simple matter to write something that can reliably tell the difference between code and comments. We use symbols and syntax in our comments and we use normal words and punctuation in our code. Generally, it's code if it parses but we'd rather not have to try parsing your comments since there is no guarantee that you commented out parseable code or even a complete line of code.

For now, use block comments to comment out code and use doc and line comments to write about your code. Then you can tell SlickEdit not to wrap block comments. Or use line comments to comment out code and tell SlickEdit not to wrap line comments. Basically, use the comment type to control what gets wrapped.

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
Re: Word Wrap and colon request,
« Reply #12 on: June 27, 2008, 09:34:08 AM »
Quote
Thanks, Graeme, that makes it much clearer. The proposal does rely on the assumption that the comments are already consistently well formatted, but it should reduce the number of times the wrong result is produced. I am concerned about the amount of processing that is necessary before we can determine what to do, though. This functionality must not delay your ability to type.

Ok.  I'll try and expand a little bit.

A line that isn't part of the current wrap region fits one of the following criteria
  • It's all blank
  • It's all blank except for bullet or comment decoration
  • It's not wrapped to the previous/next line when it could have been (end/start of paragraph)
  • The indenting of the first non blank character on the line doesn't match
  • The line is longer than it would be if it were wrapped
  • The line contains one or more instances of "two or more consecutive spaces" (configurable)
  • The line matches a regex or special character sequence
  • The number of lines in the wrap region determined from the above is less than the "start wrapping on line" configurable options setting

Which can be summed up as you say  - that the current wrap region is determined by the fact that it is "consistently well formatted" as if it has had comment reflow applied to it.

Note that it's necessary to determine the start of the wrap region using the same criteria as the end so that if you change the first word of the first line of the region, it doesn't get wrapped back to the end of the previous line.

I don't know how often slick currently calculates the end of the current wrap region but I'm guessing it does it every time it reflows a comment and the reflow propagates right to the last line of the paragraph.  I suspect it's feasible to determine the last line of the current wrap region only when the content of the wrap region is first changed  - this would help the potential performance issue with regex's and also means you don't get additional lines added to the end of the wrap region as the last line gets to its max length.

The above criteria probably takes care of undesired wrapping of commented code better too and also tabular type data as mentioned by chrisant.  As I mentioned before, it should be possible to turn "intelligent comment wrap" on/off on the fly too.

There's another feature I would also like which is the ability to show the current wrap region/paragraph (corresponding to where the cursor is) in a different colour or with something in the margin.  This means you would immediately realise when wrapping is going to be applied where you don't want it and can turn it off.  After the wrap region has been "highlighted" you could then allow the wrap region to be extended or reduced manually in some way.  There could be a delay of say half a second before the wrap region highlighting shows up (after any key-press) so that if you cursor quickly through a comment, you don't see the text colour changing rapidly!

There's another issue which is that if you allow special character sequences or regex's to determine whether a line is wrapped or not, every time you change something (insert/delete/replace characters), you potentially have to rescan the current line to determine if it does or doesn't match any more (if intelligent comment wrap is enabled).  I thing this rescanning on every change could be deferred and the determination of whether the current line is part of a wrap region or not shouldn't change while you're actually typing on the line.  It could be deferred to when you press ENTER or when you use reflow comment or turn comment wrap or intelligent comment wrap on/off. 

Another possibility is to allow a block comment start sequence of say /*# as (optionally) meaning that comment wrap is disabled in this block comment.  Then you can comment out code using /*# at the beginning.  If the code contains embedded line comments that you want wrapped you can temporarily turn intelligent wrap off.

Graeme