Additional syntax properties

[balthisar]

Some text editors — in addition to coloring syntax elements — can specify basic styles such as bold, oblique or italic, and underlined. Any thoughts?

[shysaur]

It's not difficult to implement, but it would interfere with the syntax error underlining and highlighting. The easiest fix for this is to set the syntax coloring attributes on the text storage instead than on the layout manager.

[shysaur]

The easiest fix for this is to set the syntax coloring attributes on the text storage instead than on the layout manager.

But this would enforce the same syntax coloring settings on every instance sharing the same text storage.

[balthisar]

But this would enforce the same syntax coloring settings on every instance sharing the same text storage.

Are there any use cases for sharing a text storage that's not a split view? Presumably a true split view should have the same syntax coloring settings.

[shysaur]

Yes but these other use-cases are meant to be used in page layout applications (like Indesign) and unless we move the ownership of the syntax colorer to the layout manager, they won't work correctly.

I agree with you that true split views should have the same syntax coloring settings, but the cocoa text system is not designed for making this simple.

The issue is that if we continue to set attributes on the layout manager instead than on the text storage, this is effectively impossible; and if we set the attributes on the text storage instead than on the layout manager, the syntax colorers of different instances of Fragaria would interfere with each other.

This last problem ideally should be solved by sharing the syntax colorer if and only if the text storage is shared, but the only way to do this (subclassing the text storage) is not a good idea because it's a model object and syntax coloring fits squarely in the controller layer. Plus, people expect to be able to substitute their own NSTextStorage in any given text view, because it makes possible for document-based app to load the text before the view is created.

This could also be done by designating a given Fragaria to be "master" of a given text storage, but this makes things complex for users and us alike; plus, how will the slave tell to the "master" that it must color a given area, if they only share the text storage?

One thing I thought after filing #71, is that the fix I thought of for that would also work for this. The syntax colorer would stop setting coloring attributes, and in - showCGGlyphs:positions:count:font:matrix:attributes:inContext: the layout manage will take care of translating the syntax group attribute (which we already use for bookkeeping purposes) to the appropriate color+underline+font.

The only issue is that if italic or bold variants of a font are selected, they might change metrics, but the only outcome would be some overlapped characters, and for monospaced fonts nothing would happen 99% of the time, and if it happens it's even desirable (you obviously don't want a bold font to screw-up your character alignment on a fixed width font). Also, I think this is mostly what Apple is already doing to implement temporary attributes, because this issue is exactly the same issue Apple is warning of in regard to which attributes are supported as temporary.

This would obviously involve moving all the NSColor properties to the layout manager and transforming them into NSDictionaries of attributes, which is definitively not a fun task to do!

[shysaur]

One thing I thought after filing #71, is that the fix I thought of for that would also work for this. The syntax colorer would stop setting coloring attributes, and in - showCGGlyphs:positions:count:font:matrix:attributes:inContext: the layout manage will take care of translating the syntax group attribute (which we already use for bookkeeping purposes) to the appropriate color+underline+font.

I skimmed thru the disassembly of - drawGlyphsForGlyphRange:atPoint:, and since it's that method which calls the underlining methods, the implementation I quoted above would not handle underlines (which is exactly the only property which Xcode does not allow to set for its syntax coloring...)

[shysaur]

(which is exactly the only property which Xcode does not allow to set for its syntax coloring...)

Anyway, after checking how Xcode draws syntax error underlines, this looks completely arbitrary to me, but I didn't look at where the underlines are stored (it looks like a different store than temporary attributes, but still not on the text storage. The text storage carries exactly no attributes in Xcode).

[shysaur]

Anyway, looking back to the root issue (but it would interfere with the syntax error underlining and highlighting), I changed my mind on the implementation I proposed before.

The easiest way is to make a new attribute for syntax error underline, move the syntax error underline drawing to - showCGGlyphs:positions:count:font:matrix:attributes:inContext:, and then the syntax colorer can set any attribute it wants (except background highlighting, but that's not an issue).

[shysaur]

The easiest way is to make a new attribute for syntax error underline, move the syntax error underline drawing to - showCGGlyphs:positions:count:font:matrix:attributes:inContext:, and then the syntax colorer can set any attribute it wants (except background highlighting, but that's not an issue).

This can't be done because custom attributes are not passed on to this method.

[shysaur]

I fear this feature will be never implemented...

[shysaur]

Fixed in 6b16cef. Attributes are now set on a private "overlay" text storage, which mirrors the text of another text storage but has a separate set of attributes. Every instance of Fragaria creates its own overlay text storage to hide the attributes to the outside world, and to other instances of Fragaria sharing the same text.