Breaking basic HTML tags when wrapped

[rgshew]

There's probably a config option to change this behavior, but if so I have not found it.

When I have text wrap on, HTML tags in the wrapping zone will break within the tag even when the tag has no attribute, i.e.:

<b> could break at < | b>, <b |>; same idea with </b>.

Can this behavior be turned off? Thanks!

[Mofi]

The characters < and > are word delimiting characters for HTML which is important for syntax highlighting. When syntax highlighting is enabled for the current file the word wrapping engine uses the /Delimiters = specification from the syntax highlighting definition in the wordfile to determine what a word is and so where a line can be wrapped.

You can remove the characters <> from the list of delimiters for HTML in the wordfile to avoid wrapping after < or before >. But this will have some negative effects for syntax highlighting. For example the closing > after a string value like <span style="..."> will not be highlighted anymore.

It's your decision if you prefer a good working wrapping or a good working syntax highlighting.

[rgshew]

Hi. Thank you for the reply. I'll probably try removing the <> characters just to take a look at how that will affect the editor.

One odd thing though. When short (single, no attribute) tags are broken by wrapping they no longer are highlighted. It could be something I've inadvertently done to UE I suppose.

Here's an example. I have a list of items using <li> and </li>. As long as the tags remain "whole" (unwrapped) they're blue. If, however, a tag wraps, it loses the highlighting and looks like plain text.

In the example I'm looking at right now, here's what I'm seeing:

content; and<
/li>

The wrapped </li> looks like text unless I turn word wrapping off, in which case it turns blue again. This is the same for any tag w/o attributes from what I've seen -- <p>, </p> etc. behave the same way as the </li>.

If the tag has attributes and a space in it then wrapping doesn't affect the highlighting. So <span class="splat"> isn't affected if it wraps between "span" and "class." One thing I noticed here is that the class="splat"> does not wrap within itself like a spaceless tag.

The file in this case has an .html extension and the broken </li> is treated the same way whether the file is viewed as HTML, XHTML 1.0 or 1.1.

Would it be possible to modify the syntax highlighting/word wrapping behavior so that tags without spaces would stay together like single words?

[Mofi]

When short (single, no attribute) tags are broken by wrapping they no longer are highlighted.

That's not surprising if you look at the words for HTML in the wordfile. It contains for example <LI> <LI </LI> but no /LI> and a line break is always a word delimiter.

Open the wordfile with Advanced - Configuration - Editor Display - Syntax Highlighting - button Open.

Would it be possible to modify the syntax highlighting/word wrapping behavior so that tags without spaces would stay together like single words?

Yes, with removing <> from the list of delimiter characters as already suggested.

A language with keyword HTML_LANG or XML_LANG activates internally in the UE syntax highlighting engine some special routines. The characters <> are recognized as word delimiters for syntax highlighting even if they are not specified as word delimiters and can be specified nevertheless together with a word for highlighting. For all other languages a combination of delimiters with a word is not possible. Exception: since UE v10.00 words can start with a single delimiter character. The wrapping engine recognizes only the characters which are really specified as delimiters. This special handling for <> enables you to highlight <b>bold</b> even when the characters </> are not specified as delimiters and so the wrapping engine will not wrap this string because for the wrapping engine this string is a single "word".

[rgshew]

I must be doing something wrong. When I change delimiters to omit <>

/Delimiters = ~!@$%^&*()+=|\{}[]:;"' , .?

(for the /L3"HTML" HTML_LANG {etc.} section)

the only difference I see is that, as you stated, in a <span> example the final > is no longer highlighted.

<b> and </b> both break at the < if that's at the wrapping point and they aren't highlighted as tags when that happens. The <span> tag, if it breaks at the < also loses its highlighting for the

<
span

part although the following foo="bar"> retains the highlighting.

I have modified word- and taglists so to be certain it wasn't something else in either of them I moved them, did a new installation, and then put the patch in place, and worked with the word- and taglists as they normally are.

What am I missing? It's probably staring me in the face, lol.

[Mofi]

Have you restarted UltraEdit after modifying the wordfile?

The syntax highlighting engine will recognize changes in the wordfile immediatelly, but not the wrapping engine.

In the taglist file nothing must be modified.

[rgshew]

Hi. Thanks again. Yes, I've been closing, restarting every time I take another whack at this, and I've done that quite a few times, lol. I'm pretty standard: Windows Professional 2000, fully patched. UE up-to-date. UE handles text, HTML, JavaScript (and basic stuff like INI files) -- for HTML I start one of several browsers from within UE. TopStyle gets the CSS files. Default browser is FF 2.0.

Update. I have a junker PC and I just installed UE on it (Windows 2000 Pro also). Removing the <> from /Delimiters didn't change anything: a <b> tag broke at the < if it was at the margin and when this happened it lost the highlighting with both variations of the wordfile.

A bug?

[Mofi]

I have tested it with UE v11.20a and v12.20a+4 before I have written my first answer and it worked.

What are your wrapping settings for HTML files? Can you post a full example line and what exactly you enter at which column when wrong wrapping occurs?

[rgshew]

I'll paste what I've been using at the end of this message.

I sent a report to UE and they confirmed the problem.

"Thanks for your message and for the feedback. I was able to reproduce what you are seeing. Currently there is not a way to support what you are looking for. You can try the workaround you've suggested, however there is not a way to resolve the other behavior you are seeing.

I will ask the developers to consider changing the word wrap behavior to not 'break' the <b> (or other HTML tags) as well as not break tags which include attributes."

Since you aren't having the problem, there could be something in the configuration that I should not have messed around with.

They didn't get all of what I described in that I suggested tags with attributes would wrap at a space (but not after < etc.). The other behavior he mentions is that when the code wraps it loses its highlighting.

I have UE set to wrap at column 80. I have "Enable Syntax Coloring," "Enable Auto Brace Matching," "Auto Correct Keywords" and "Brace Match In Comments" all turned on.

Here's the code:

<html>
<head>
<title>Test</title>
</head>
<body>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed didam nonummy <b>bold</b> Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam <span class="foo">bar</span>.</p>

<p>Lorem <b>ipsum</b> sit amet, <span class="foo">consectetuer</span> adip.</p>

</body>
</html>

It breaks at the < for the bold and span tags in the first paragraph. The second one was there just to see how changing /Delimiters would affect the coding.

I hope this message made sense. I fell off a ladder today and am full of Vicodin!

[Mofi]

Okay, you use soft wrapping (wrap for view only) with Wrap after column # and I have tested it with hard wrapping (really break up the lines) with Wrap after column #, insert CR/LF and Automatically insert CR/LF when file is opened. With hard wrapping it works according to my description. With soft wrapping the wrapping and syntax coloring really does not make it correct.

Maybe you create with button Change List a list entry for HTML files and specify for the HTML files to use hard wrapping. The additional line breaks with <> not in the list of delimiter characters will (normally) not have an effect on displaying the HTML files in the browsers.