vote, for a finer form@fix

Here is a roadmap, for improving form@fix. (The formerly offered-list is kept, too.) The most recent version is reflected in the form@fix reference manual.

How to vote, for a wish-list

There are mainly two ways, for letting your wishes, get implemented in form@fix.

The first way is to affirm or reject, any proposal I list on this page.

Alternatively, any reader may suggest a feature, from any text I list - any textbook, magazine, or journal. This is only another way of voting. Refer to the idea, with the page-no of that text, where the idea is published. I have strategies for this, along with the list of those texts. Please, read them, if you would like to suggest.

Who May Vote?

Mainly two types of people. The registered users, and other identifiable (i.e., non-anonymous) people. At this point of releases, the form@fix is not yet a payable/registerable software. (You may also read my prospective software-license agreement.) Currently, the only way for acceptable-votes is being identifiable as a real-person(ality), not an anonymous one. Most easily, that may be a person identifiable through an [academic or other well-known] institution/position. Unfortunately, this excludes even people like myself, because I am self-employed, and unless you already know-me-with-my-name in real life, you may not be able to tell whether my name (written at the footer of every page at this site), is a real, or a nick-name. I may be known, in person, by only a few thousands of people, I guess.

On Patents, Plagiarism, etc.

My spontaneous, very original to form@fix, proposals are likely to be on the very-idiosyncratic aspects of it, not likely to be found, in that combination, anywhere else. Even so, if you notice that any proposal I list, stands to infringe some patent, copyright, etc., then please inform me before I implement them, at all. This is a convenience for both the form@fix-users and myself. (Please visit that strategies page, if you would like to read more about this issue.)

What Next?

? Revoke on Frame-Return

A frame, if revokeable, would leave no trace after return. The revokability is defineable as automatic, or manual. To implement this, is very easy, if only the frame remz-list (the references) is revoked (cf. #undef in C, or the variable-name-referral, global-vs-local, or function-in-function, in any programming-language).

If a full-revoke is wanted, there must exist log-keeping, too, for any modified byte, of Arz - and even to reverse, if any file was modified. That would resemble the database-transactions, or the termination of deadlocked code in some operating systems. Needed, here?

? Import vs. Include?

The difference is about the precedence/overriding/cascading of the defined remz-list (name-space, cf. XML/CSS/etc). A remz is redefineable temporarily, or permanently. All of the frame (as with frame-revoke), or remz-by-remz.

• to redefine a remz, as \r! is implemented, forgets the old address
• if new-level were allowed, the most-recent defined, would remain as the remz found with that name - until revoked.