Looks like something changed in the OT compiler in G3. This used to be possible in G2, but G3 rejects it.
How to unset the lookupflag and then ignore marks? It needs to be in two lines now?
Still topics need to be 15 characters?
Currently, lookupflag 0; needs to be separate, yes. Are you sure you need it here at all?
Perhaps @Grzegorz_Rolek can take a look at this and decide on the zero.
I suggested a topic that will also make it easier to find this thread again.
1 Like
Each lookupflag statement resets all current lookup flags by default, so all you need is:
lookupflag IgnoreMarks;
Just remember that there are no scopes in the feature code syntax, so a statement like this will also reset flags outside that lookup block.
I’m not sure why makeotf (thus also Glyphs 2) supports that, but using 0 to reset lookup flags was a special case of setting all the flags at once with a single integer, so it was never meant to be mixed with the human-readable flags as far as the syntax goes.
Furthermore, setting lookup flags with an integer has all sorts of problems. For example, if you want to reference a mark filtering class, you’d have to known in advance the precise class index in the GDEF table, and you cannot know that for sure, at least not when writing normal feature code. This is not even supported in Glyphs 3.
I’d advise not to set lookup flags with integers anymore. In Glyphs 3, you can reset flags with just lookupflag; and it will have the same effect as lookupflag 0;. That saves a bit of code, makes more sense when used with the human-readable flags, and it looks nicer as well, doesn’t it?
3 Likes
Thanks @Grzegorz_Rolek, that clears things up!
Shall we add an error message like ‘lookupflag 0 is not necessary; fix: remove 0’?
No. The ‘0’ is present in a lot feature code. This would produce a lot noise.
1 Like
I think @mekkablue referred only to the original code:
lookupflag 0 IgnoreMarks; # error message with fix-it button
lookupflag 0; # no error message
Yes, the support for lookupflag 0; has to stay for backward compatibility without any notices or issues. It’s only the mixed form that would get a fix-it notice, if anything.
But then, I’ve never seen the mixed form before. How common is it? Should we consume it at all?
Bendy, have you seen that in the wild or is it just you?
I believe I’ve seen it elsewhere, but I’m not certain. But if the IgnoreMarks flag resets all the other flags (e.g IgnoreBaseGlyphs, UseMarkFilteringSet) then I can see it’s not strictly necessary to put the 0 in there. At least in theory 
Thanks for all the input!
Yes. This is why I tend to put lookupflags explicitly on every lookup. When moving the lookups between features to try and get things working in the right way, previous lookupflags can easily be an unexpected source of confusion.
I found another difference in the G3 OT compiler. This used to be possible:
The problem goes away if I remove the square brackets on the final glyph. I just wouldn’t have expected a class of one glyph to cause that error.
Nice catch! I’ve never been sure whether to allow singleton classes in places where classes are disallowed by the spec. I’ve just found a note in the code on exactly that issue 
I’ll silence that error, but please note that the explicit use of single glyphs vs single-glyph classes in target glyph sequences is semantically significant, the latter enforcing a class-based lookup subtable format if available. That can result in different output.
2 Likes
Good to know, thank you!