Hi,

I'm using the wordfile for ini file syntax and I see that the last section in the ini is not detected as foldable. This is of course due to the fact that the Close Fold Strings include only the "[", meaning the beginning of another section. Is there a way to denote EOF as a close fold string/indication? Or maybe there is another way to fix this annoyance?

BTW, the same happens with the wordfile which highlights a wordfile syntax. The last /C section is never detected as foldable.

Thanks,
Arnon

I'm the author of both wordfiles and the answer is NO. I have sent a feature request by email to IDM support, see below. But enhancements are implemented in UltraEdit mainly depending on the number of users which request a feature. So as long as I'm alone with that feature request, I suppose, I will never see that enhancement. So please request such a feature also by email to IDM support.

---

UE - Feature request - EOF as close fold string location

This is not a problem report, it is a feature request. Code folding is a very useful feature. It is designed mainly for programming languages, but many other users and I too use it also for other file types. Such files often have blocks which only have a "block start string" and the block ends on first blank line, or with the line termination of the line above next line with a "block start string", or at end of file.

It is no problem to use the code folding for such blocks of non programming languages because it is possible to define the "block start string" as open and as close fold string. With additionally using ignore fold strings it is further possible to avoid wrong interpretation of a "block start string". In the attached wordfile there are 2 languages with fold strings for non typical usage: /L2"Settings Files" and /L10"IDM Wordfiles".

/L2"Settings Files" and /L10"IDM Wordfiles" are good examples to show you the general problem of code folding used for blocks not having an end of block marker string. The last section in an INI file or the last color group in a wordfile can't be folded with a simple click on the [-] symbol left the block starting line because there is no method to tell UltraEdit that the end of the file is the end of the last block and therefore there is no [-] symbol left the last block starting line.

That is an unsatisfactory fact at the moment. And that's the reason why I wrote this feature request.


One possibility to deal with the problem that for some languages the end of a file (short: EOF) is also the end of last foldable block is to automatically interpret EOF as close fold string location when following rules are all true:

• The active file is syntax highlighted and the used syntax highlighting language contains open and close fold strings.
• There is only 1 open fold string.
• There is only 1 close fold string.
• Open and close fold strings are identical.

All 4 rules are true for files highlighted with /L2"Settings Files". It is 100% clear that for files highlighted with a language which only has 1 open and 1 close fold string and the string is the same that those files are structured in blocks where a block ends either on start of the next block or at EOF. So UltraEdit could automatically interpret EOF has close fold string location for such files.


However, the automatic interpretation of EOF = close fold string location would be of no help for /L10"IDM Wordfiles". When more than 1 open/close fold strings are defined, it is impossible to evaluate by UE/UES, if EOF is now a valid close fold string location or not.

For such files respectively languages it would be good when a wordfile creator could explicitly define that EOF is always a close fold string location. I suggest a special string which could be used by a wordfile creator and recognized by UE/UES with its special meaning. Because I always take care about downwards compatibility I suggest "#IDM-EOF#" as close fold string which is interpreted by a future version of UE/UES as "EOF is valid close fold string location". We can be quite sure that there are no files containing the string "#IDM-EOF#" already as close fold string and therefore wordfiles with such a close fold string would have no bad affect when used with older versions of UE/UES.

The code folding definitions of /L10"IDM Wordfiles" would look with that enhancement as follows (close fold strings are all on 1 line):

/Open Fold Strings = "/C1" "/C2" "/C3" "/C4" "/C5" "/C6" "/C7" "/C8"
/Close Fold Strings = "/C2" "/C3" "/C4" "/C5" "/C6" "/C7" "/C8" "/L2" "/L3" "/L4" "/L5" "/L6" "/L7" "/L8" "/L9" "/L10" "/L11" "/L12" "/L13" "/L14" "/L15" "/L16" "/L17" "/L18" "/L19" "/L20" "#IDM-EOF#"
/Ignore Fold Strings =  "// /"

While we're talking about fold strings, I've suggested to IDM that they introduce a new type of fold string:

/Open Fold Strings = ...
/Mid Fold Strings = ...
/Close Fold Strings = ...
/Ignore Fold Strings = ...

"Mid Fold Strings" would allow a user to explicitly define keywords on which UE should add a fold between an open and close fold string. Examples of "Mid Fold Strings" would be the Then and Else keywords in an If/Then/Else/End If construct. If, like me, you feel that this would simplify the definition of fold strings in UE wordfiles, then please email IDM with your request for it as well. Also in my suggestion to IDM was the support of regular expressions in fold string definitions.

I definitely believe that all open fold strings should automatically be closed at end of file.

As UE is looking at better management of XML and HTML, HTML is a prime example of a language that will close any open tags at the end of the document. Also, with PHP, the opening tag does not need to be closed if the file ends, and as this is a "folding string" for me, it would be helpful for it to close at end of file. I always, purposefully, leave off the closing ?> at the end of a PHP file to prevent any characters from being present after the final closing tag. Any white space after it can cause headers to be sent prematurely when it is an included file.

I can think of other examples as well.

As for the /Mid Fold Strings =, bulgrien, I think that is a fabulous idea. I am often frustrated by the way if/then/else/end if works in regards to code folding. Else needs to be both an END to the folding AND a BEGIN to the folding. Mid fold strings would be an excellent solution for this.

I will shoot an email to IDM for both features.

Note to Mofi: You may want to update that wordfile to include /C8 ... /C20 now.

rhapdog wrote:HTML is a prime example of a language that will close any open tags at the end of the document.

That statement is not 100% correct. According to HTML 4.01 specification for some block elements like P, LI, TR, TD, ... the end tag is optional and not required, although it is usually not a good idea to omit the end tags because that makes interpreting the HTML file more difficult for everyone, the browsers, the editors and the humans. But for many others like TABLE, PRE, STRONG, SPAN, ... the end tag is required which makes the HTML file invalid if missing.

Well, I can remember a discussion 10 years ago about which browser is the best based on error handling. Most users just visiting webpages in WWW about the year 2000 vote for IE because the Microsoft developers have implemented thousands of code lines (several MB in compiled code) to auto-correct errors in HTML files and display them correct even when the HTML file is full of errors. On the other hand there were the purists of the HTML writers (like me) using a text editor for writing HTML files and not using a WYSIWYG HTML editor producing permanently invalid HTML files like MS Frontpage 2000. They vote for other browsers which display garbage if a HTML file contains errors instead of auto-correcting them because then the author could immediately see that something is wrong in code of the HTML file which would result in uploading only completely valid HTML files or at least HTML files with small mistakes to the servers. It is not surprising that the much larger group requiring browsers fixing errors in HTML files won. Most webpage authors use WYSIWYG (almost) HTML editors don't know the syntax of HTML and I think, most programmers of these editors about the year 2000 have also never read the HTML and CSS specification.

Therefore I prefer that UltraEdit does not automatically close all folds on end of a HTML file because then the code folding is a helpful feature to see where something (could be) is wrong in the HTML file. Those using a text editor to write HTML files or to correct WYSIWYG created HTML files are likely interested in producing valid HTML files.

Regarding the Mid Fold Strings, here is what I sent to IDM in April 2010: http://screencast.com/t/MWZmN2RlOWYt