Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional syntax properties #70

Closed
balthisar opened this issue Mar 21, 2015 · 10 comments
Closed

Additional syntax properties #70

balthisar opened this issue Mar 21, 2015 · 10 comments

Comments

@balthisar
Copy link

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

@shysaur
Copy link
Owner

shysaur commented Mar 21, 2015

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
Copy link
Owner

shysaur commented Mar 21, 2015

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.

@shysaur shysaur self-assigned this Mar 22, 2015
@balthisar
Copy link
Author

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
Copy link
Owner

shysaur commented Mar 22, 2015

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
Copy link
Owner

shysaur commented Mar 22, 2015

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
Copy link
Owner

shysaur commented Mar 22, 2015

(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
Copy link
Owner

shysaur commented Mar 22, 2015

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
Copy link
Owner

shysaur commented Mar 22, 2015

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
Copy link
Owner

shysaur commented Mar 22, 2015

I fear this feature will be never implemented...

@shysaur
Copy link
Owner

shysaur commented Apr 28, 2019

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.

@shysaur shysaur closed this as completed Apr 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants