Advanced Features
This page describes features of interest to power Arachnophilia users -- how to exercise greater control over the FTP service, how to list and use Arachnophilia system commands, and some other things.
The macro list at the left in the main Arachnophilia display is actually a sort of telephone switchboard that links menu items, toolbar buttons and keystrokes to Arachnophilia commands (as well as user-entered text). The Arachnophilia command list is rather long, and not all the commands are represented by a menu item or toolbar button in the default configuration.
To see a list of all the commands, use Tools ... List System Commands. This is a very important list -- remember where it is located and refer to it often. Some of the less-often-used commands are only described in the list itself, nowhere else. And any of them can be included in the macros you write.
Some Arachnophilia commands accept arguments, which allows the user to create specific, powerful commands. An example might be:
[FindReplaceAll:/cat/dog/]
This type of macro makes it unnecessary to manually enter search and replace text for common operations.
In summary, there are many powerful commands in the list, some not listed or described anywhere else. It is a good idea to review this list before asking for a feature that already exists .
Some platforms must distinguish between text and binary files, in order to process text file line endings. FTP services ordinarily maintain a list of file suffixes and their respective types. Arachnophilia maintains this list as part of its file type configuration file.
The file type configuration file is located at:
(user home directory)/.Arachnophilia/FileData.txt
This file is self-documenting and contains a record for each file type. Each record distinguishes between binary and text file types.
To add a text file suffix, let's say "xyz", simply add it to an existing text file type, like this (change in red ):
Text|t|-|txt,text,doc,bat,log,tbd
,xyz
; text files
Or, you might want to add a new file type simply to contain text file type suffixes, like this:
TextFileSuffixes|t||abc,def,ghi,jkl ; text file types for FTP
The FTP service defaults to binary file type (after build 1860) but, to make its final determination, it searches this configuration file for any entries that identify a file type as text.
The FTP service has a debugging facility, controlled by the slider control at the bottom of the FTP dialog. To see more debugging messages, simply slide the control to the right and run the transaction. Each increment to the right increases the level of detail.
I receive many "bug reports" from users that simply say "The FTP transaction just stopped." Users need to look at the debugging messages to find out what actually happened.
Systems differ widely as to the sort of destination path entry they require. Some systems require that the path begin with a forward slash ("/"), some must not have this, others do not care. This is a very common debugging problem.
Example -- let's say you have a Web site with a target directory of "WebPages". Depending on the operating system the server is running, you may have to make any of these entries for a destination path:
WebPages
/WebPages
~/WebPages
/
The easiest way to sort this out is to ask your service which option is correct, but reading the full debugging trace always helps. The destination side will usually complain if the entry is not correct. If you do not use the above-described debugging facility, you may never know why the transfer failed .
The HTML beautifier will indent your HTML page just as code beautifiers do, except there can be problems one does not see in code beautifiers. Most of the problems are caused by inconsistent HTML syntax -- some tags have closing partners, some do not. And some tags have closing partners sometimes, but not other times, both legally. Example:
<p align=left>My paragraph</p> (also legal)
My paragraph<p> (legal)
Because both these forms are legal, and because there are many such legal examples, there is no meaningful way to write a reliable, robust HTML beautifier, something I discovered far too late. But the beautifier can be made to behave itself in most cases if the user avoids one or another form of ambiguous tags. This is accomplished by way of some user-editable configuration files located in this directory:
(user home directory)/.Arachnophilia/HTMLBeautifyData
The most important file in this directory is named "BeautifySoloTags.txt", which contains a list of tags that do not have closing partner tags. Each of the configuration files is self-documenting.
To summarize, if you find the beautifier indenting in anticipation of a nonexistent closing tag, add that tag to the list. If you find the beautifier not indenting a tag that it should, remove that tag from the list. If you cannot bring yourself to follow consistent HTML coding practices, do not try to use the beautifier. And whatever you do, do not write to tell me that the HTML beautifier is broken. It is HTML that is broken, not the beautifier (see below).
The previous major version of Arachnophilia (4.0) had a much more ambitious beautifier that also tried to correct HTML syntax. This facility only reflected my naive optimism about HTML standards and committees. It turns out that the HTML standards committees will accept any imaginable thing that anyone says they want.
Also, browser manufacturers sometimes simply introduce a new tag, or a variant on an old one, without bothering to consult the specification, probably hoping to break their competitor's browser. I think they secretly hope a Web page will display perfectly on their own browser, while an adjacent computer running the "brand X" browser will burst into flames.
The fact that the above example of <p> and <p></p> can exist, both forms legal (there are many such examples in HTML), only shows that the standards committees are staffed by people who know next to nothing about computers and computer languages. These misguided souls think computer languages are like human languages. In fact, the only thing they have in common is the name.
In human languages, you can have two seemingly distinct words -- like "flammable" and "inflammable" -- that actually mean the same thing, and no one raises an eyebrow. You can have a dictionary listing for "figuratively" that identifies it as a synonynm for "literally" (true!), and no one seems to mind. But these absurd properties of human language cannot be included in computer languages, because computers are not nearly smart enough to cope with such ambiguity.
Nevertheless, HTML has embraced all the worst parts of human languages, to the degree that I am reminded of the parent who wailed, "I used to have six rules and no children, now I have six children and no rules." Standards committees need to learn a new word -- "No."
But it is too late for HTML, which might as well be thrown out and replaced by something designed more strictly, like XML.