SortLanguage User Tool

[rhapdog]

Current version: 1.10

Download Here

About the program:
SortLanguage is a command line tool that takes as a parameter a filename that points to an UltraEdit wordfile. It will then sort the words in the word groups of that wordfile according to the specifications allowed for wordfiles and will "wrap" at column 80 by default, or a different wrap location can be specified via command line switch.

Invoke the program without any parameters to get help on how to use it.

Set it up as you would any console-based command line tool.

EDIT: As of July 16, 2012, version 1.10 is now production ready! Happy sorting!

[rhapdog]

I have really come a long way with the sorting, and think I have improved somewhat on your macro, Mofi:

Here is a sample line from /C1 from the "html.uew" found in the "User Submitted Wordfiles:

Mofi's sort macro (version released on 2012-05-29):

Code: Select all

<A </A> <ABBR> <ABBR </ABBR> <ABOVE> <ACRONYM> <ACRONYM </ACRONYM> <ADDRESS> <ADDRESS
</ADDRESS> <APPLET </APPLET> <AREA <ARRAY>

My tool:

Code: Select all

<A </A> <ABBR <ABBR> </ABBR> <ABOVE> <ACRONYM <ACRONYM> </ACRONYM> <ADDRESS <ADDRESS> </ADDRESS> <APPLET
</APPLET> <AREA <ARRAY>

As you can see, mine sorts:
<ACRONYM <ACRONYM> </ACRONYM>

And yours sorts:
<ACRONYM> <ACRONYM </ACRONYM>

Looking at it logically, <ACRONYM should come first, since it is a shorter word that <ACRONYM> adds one character to. Not that it matters to UE, as long as they are on the same line.

I noticed your macro doesn't "wrap" lines properly for HTML Tags < </ at the front of a word, as it doesn't take into account the extra '_' you place at the end when sorting. Mine, however, will wrap perfectly in every instance.

[Mofi]

Thanks, I downloaded the version 1.08 Beta and continue with writing test cases and testing the tool. The test with Nocase are still missing in my test suite. I agree that the sort order of words with values greater 0x7F does not really matter as they are extremly rare in the wordfiles as we already know.

BTW: In C/C++/C# there is a compiler switch which controls if variables of type char are interpreted as signed char or as unsigned char. For storing and printing strings it does not matter if char is signed or unsigned. But when comparing characters as done for example during a sort, it is important if single byte character arrays are of type signed char or unsigned char. Perhaps the programming language you use have also such a compiler switch which determines the type of characters.

Hint for others reading this and being interested in char versus signed char or unsigned char

GCC:
Options Controlling C Dialect - Parameter: -funsigned-char and -fsigned-char

Visual Studio:
/J (Default char Type Is unsigned)
Data Type Constants

Wikipedia:
C data types

By default C/C++/C# compilers interpret char as unsigned char. Therefore the type char should never be used for variables holding 8-bit values for calculations. The type signed char or unsigned char should be used for 8-bit variables used for calculations like in CRC or checksum calculation routines working usually only with type unsigned char, but also with char as long as the compiler switch is set to interpret char as unsigned char.

[rhapdog]

Fabulous suggestion, Mofi. That's one of those things that sit right in front of your nose and you never see it because you've been staring at it for too long.

I checked, and there is no compiler switch for it.

Thanks for that suggestion. Although it's not going to do me any good. I can't even implicitly cast a "char" value as either signed or unsigned. Only numbers, not characters.

The language does, however, according to definition, interpret char values as unsigned automatically. Seems it really is a bug in that library.

[rhapdog]

For anyone that has been waiting on an updated status for this project...

Mofi emailed me the last test report, and all errors have now been fixed in the program.

The program is now at version 1.10 and is production ready! Users may now download the tool and use it freely.