Nedit -- wrap

[Tony Balinski]

Quoting Thomas Orgis <thomas-forum at orgis.org>:

> Am Mon, 4 Jun 2007 07:58:18 +0100
> schrieb "Waring, Steve (Central-Networks)"
> <steve.waring - central-networks.co.uk>:
>
> > Not a bug, but a feature I think would be really useful, would be to
> > have another wrap option, perhaps called no-break. Basically to work the
> > same way vi works, wrapping the text exactly where it reached the right
> > hand side of the window, part way through a word, rather than at a word
> > boundary.
>
> Hm, a possibility...
> 	another visual improvement would be indendation of the
> 	dynamically wrapped parts of the long line to the
> 	beginning of it,
> like I did here... of course I mean only indendation for the visual
> epresentation, soft indent just like the soft line break.

Both of these are excellent suggestions IMO. I believe Textpad on Windows does
the latter. The only issue is if your left hand indent is very deep, close to
your right hand margin. (I can't remember what Textpad does in this case.)

> > Also, the Korn shell syntax highlighting becomes completely messed up if
> > you have code using inline stdin that contains quotes, such as.
> > cat <<EOF
> > This single quote ' messes up the syntax highlighting.
> > EOF
>
> Hm, it does so for Perl's print <<EOT; ... EOT, too.
> Is it possible to handle with nedit's syntax regexes (expecially since the
> "EOT" is not fixed, can be any string)?

I adapted my shell SH rules to allow for this, but my solution isn't ideal.
I have a pattern called "inline stream" which is included after "double quoted
escape"; it's Pass 1, "Highlight text matching regular expression":
  \<\<-?\s*(\w+>)\s*\n((.*\n)*?)(\t*\1)\s*$
which, as you can see, will match multiple lines, something to be avoided with
SH REs. I set the context requirement to 3 lines, so sometimes the
highlighting will get lost while editing (the reason this practice isn't
recommended). The parenthesised expressions \1, \2 and \4 can be used to
highlight the start marker, the content and the end marker (same as the start
marker) in separate "coloring for sub-expressions" SH rules.

In a similar way I have "improved" case/esac recognition, which also has a
fragile relationship with the context length.

Even though these rules are fragile, I find them more useful than ignoring the
constructs they highlight. (I realise that others think differently and would
avoid context-length dependencies entirely.)

Tony