1. What font editor are you using?
2. What application(s) are you testing your font in?
3. Have you read this: Adobe Feature File Syntax information

Scripting should not be necessary. Substitution allows for more than one-to-one, but you have to write it correctly and more importantly the app you intend to use the font in must support it. Check the Adobe Developer site linked in #3 above and read up on the syntax. I think it will save you a lot of time and frustration.

This is the newest Feature File Specification:
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html
I think that type of automation is no good idea, unless you want to make your font unusable. In my example I used Stylistic Set, so user must chose this behaviour intentionally.
Anyway:
"sub comma hyphen by comma_endash;"
better
sub comma hyphen' by endash;
"replace 1 followed by x by a '1×'"
sub @numbers x' by multiply;

full .fea file:
languagesystem DFLT dflt;
languagesystem latn dflt;
@numbers=[zero one two three four five six seven eight nine];

feature ss01 {
sub @numbers x' by multiply;
sub comma hyphen' by endash;
} ss01;

1. FontLab Studio
2. FontLab Studio, Illustrator, InDesign
3. I hadn't read it until now. It probably doesn't solve all my problems (I still prefer asking about specific problems and see best practices) but it does create new possibilities already.

Scripting should not be necessary.
What do you mean by this? I've seen that in some software like Glyphs the scripting is done for you, but somehow I still prefer to do it myself. At least I know what exactly is going on in the back end, and I would like to use the software most type designers use so that I can ask questions if necessary. There are already too few tutorial videos on FontLab. It might be worse for other software. However I'm interested in hearing what you might use to improve the workflow.

I think that type of automation is no good idea, unless you want to make your font unusable.
Why isn't it a good idea? How does it make the font unusable? I have no problem with putting the scripts in stylistic sets, but I thought it was a good idea to fix as many issues as possible with the standard ligatures set.

sub comma hyphen' by endash;
I read that the hyphen defines the glyph to be replaced. Does it ignore the comma in this case? I guess this is the better way to script because you can still perform tracking on the comma and endash, right?

@numbers=[zero one two three four five six seven eight nine];
Where would you put this line of code? Underneath the language statements or inside the stylistic set? I want the x to be replaced by a multiply symbol after any kind of number. Do I need to define all number sets in "@numbers=[]"?

In my example I used Stylistic Set, so user must chose this behaviour intentionally.
Why is it better in this case to choose it intentionally? Are there contexts in which you would want to use comma-dash and x inappropriately?

Thanks a lot for the tips!

It's generally a bad idea for a font to change the actual character codes instead of just changing glyph variation, even if this is done in an attempt to fix sloppy typesetting. Sometimes people really do intend the characters that they type. For example, consider an algebraic expression y = 3x + 15

There was a discussion of this some years ago here, with many useful comments on the problem: http://typophile.com/node/34108

"you can still perform tracking on the comma and endash, right?"
Right
"@numbers=[zero one two three four five six seven eight nine];
Where would you put this line of code?"
If you want to use this Class in another functions, declare it outside any features (globally). If it is to use only once - inside the feature.
[named lookups behave differently - declared globally or locally are always available]
"Do I need to define all number sets in "@numbers=[]"?"
All 10 digits are defined already.
Thanks DTY, excellent thread.

"2x2=4
2 x 2 = 4"
feature ss02 {
sub @numbers x' @numbers by multiply;
sub @numbers space x' space @numbers by multiply;
} ss02;

They're all scripting languages, whether it's Python, OpenType, CSS, Javascript etc.

In a very broad sense, OpenType features could be seen as a form of scripting language as they define a set of rules for the interpreter to follow, but what is usually called a scripting language has many more characteristics than that and basically no one in this industry refers to OpenType features as such. It’s also why no one calls CSS a scripting language, but rather a style description language.

To me, OT feature code feels more like a kind of advanced search and replace, like grep or regex, at least with GSUB. GPOS is more like a lookup table.

"sub [f f]' question by f_f.alt;"
I believe this line works like this:
IF \f \? or \f \? is met THEN \f is substituted by \f_f.alt
[nota bene: second \f !]
so output is: \f \f_f.alt \question
You probably want:
sub f' f' question by f_f.alt
(see OpenType Feature File Specification, 5.f.i. Specifying a Chain Sub rule and marking sub-runs, Example 4. Link)

It’s also why no one calls CSS a scripting language, but rather a style description language.

I've been calling it a scripting language. Apparently incorrectly so, although I appear not to be the only one when I search on Google.

Not counting scripts written as add-ins for font editors, the only time I've seen anything pertaining to fonts referred to as "script" pertains to writing systems. For example, Latin, Cyrillic and Greek are all scripts.

I've been calling [CSS] a scripting language. Apparently incorrectly so, although I appear not to be the only one when I search on Google.

You know, there are people that say HTML is a programming language, and this despite the Markup in its very name… But that’s just nomenclature. Really what matters is clear communication, and the misunderstanding you had with George speaks for itself. Regardless of what the reasons are, throughout those twenty years ‘scripting’ just never got it into the OpenType terminology.

I'm tired of people over-hyphens so I wanted to script a fix for that, so in the standard ligatures I put the following code: sub comma hyphen by comma_endash;

This replaces the comma followed by a hyphen with a ligature glyph where I have a comma followed by a line which is in between the hyphen and the en dash in length, which is more appropriate for denoting prices ($50,–).

Now I want to do the same fix for "x" after numbers, so every time an /x is typed after a number it's automatically replaced by a multiply symbol.

It's one thing to replace a sequence of letters with a ligature, but I question whether the type designer should fill the role of a copy editor any more than the layout application should do so. A type designer's role, I think, should be to create a well-designed font, not to ensure that the end user adheres to a preferred punctuation style.

Now I want to do the same fix for "x" after numbers, so every time an /x is typed after a number it's automatically replaced by a multiply symbol.

A type designer's role, I think, should be to create a well-designed font, not to ensure that the end user adheres a preferred punctuation style.

Agreed. Add to it that there are plenty of instances where this can go wrong (and it will, as per Murphy's Law), and that there are few more infuriating things than software that tries to outsmart you...

Agreed. Pretty much nobody calls writing OpenType code “scripting,” and doing so is likely to lead to confusion.

Not saying it would be crazy to refer to it that way, just unwise. :)

What would one call writing OT features though?

As for the punctuation fixes... I personally feel that to the extent that we can exert control over the typography we should do so. The graphic design course I'm following is completely lacking on typographic education and when I look at the typography on the streets I see errors all the time so apparently some solution is necessary. By the time we will graduate I'm convinced more than 90% still won't know the difference between a hyphen and an en-dash and still won't understand that the letter /x is not a multiply symbol. If the editors aren't preventing these errors, then who else should do it? I think an OT feature accessible by a stylistic set is a nice solution.

but I question whether the type designer should fill the role of a copy editor any more than the layout application should do so.

What about spell check for those who can't or refuse to spell correctly? Years ago you might have said this is the editor's job but an automatic solution is much more practical and elegant and I think you would have admitted to that then. To be honest I don't think the solution should be in the typeface but right now no one else is solving the problem, except for editors doing manual work but apparently many design agencies have no such editors.

Regardless of whether writing OT features is considered scripting, it can be considered programming or coding.

As an example of the complications that Riccardo mentioned, I thought of another case: y = 2x² (I used U+00B2 here as a Typophile interface hack, but in real life it would be set as an ordinary “2”, with superscript style applied either fake or through OT substitution.

Years ago you might have said [spell check] is the editor's job but an automatic solution is much more practical and elegant and I think you would have admitted to that then.

Indicating a misspelling automatically is one thing, but autocorrection done in a way that you possibly don’t even notice is another. Riccardo’s right when he says that those things can really go wrong, just like autocorrection does these days. Either you or the editor would have to look through those substitutions each time the text changes anyway, so why not do it at the character level in the first place?

One example of a similar mechanism not doing what it is supposed to do: When you type ' (U+0027), MS Word AutoCorrect will try to guess if this is supposed to be a single opening quotation mark (after a space) or a single closing quotation mark (after any character other than a space). Apostrophes are treated like closing quotation marks, but that’s not a problem—in English. In German, single closing quotation marks and apostrophes are not represented by the same character ’ (U+2019). Rather, apostrophes are ’ (U+2019), as in English, whereas single closing quotation marks are ‘ (U+2018). But AutoCorrect can’t tell. You could try to come up with a better substitution rule (based on the character that follows). As long as that doesn’t happen, each and every German-language document created in MS Word with AutoCorrect switched on will have the single closing quotation marks wrong.

I would also advise against trying to improve the microtypography of a text through OpenType features, for two reasons: First, Murphy’s Law. Second, this kind of replacements will screw up the encoding of the text. It will lead to glyphs being replaced by other glyphs that don’t belong to the underlying character. This would also have the undesirable effect that, when you replace your typeface by another, all typographical ‘improvements’ will be lost. If you want to promote rule adherence on the microtypographical level, write a script for InDesign that performs replacements (like the ones you have in mind) on the character level. Many typesetters have created such scripts for themselves, but if you come up with something that’s cleverer and more comprehensive, there would certainly be a market for that.

Regardless of whether writing OT features is considered scripting, it can be considered programming or coding.

I use the term 'Feature Coding' or 'OpenType Coding'.

While the term 'programming' is frequently encountered, I personally think it is a bad idea to use this term in reference to OT coding because it ultimately can lead to all sorts of misconceptions about what you're actually doing when you code features. The language used by AFDKO (and, by extension, FontLab), describes static data tables. Thinking of it as a programming language can mislead people into thinking that they are creating algorithms rather than describing data, which will sometimes result in confusion over how a particular feature will actually behave.

André

I would use "coding", not "programming" (which is something more serious).

This is a domain-specific language (like CSS or HTML):
http://en.wikipedia.org/wiki/Domain-specific_language