Skip to content

Add support for ngdocs #288

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

Closed
wants to merge 1 commit into from
Closed

Add support for ngdocs #288

wants to merge 1 commit into from

Conversation

whitneyit
Copy link
Contributor

Added support for angular's own ngdoc syntax.

@Delapouite
Copy link
Contributor

I would prefer this syntax highlighter to remain framework specificities free.

@qstrahl
Copy link
Collaborator

qstrahl commented Aug 18, 2015

I'm actually in favour of this; this is unlikely to affect anyone not using angular, and would be nice to have for angular users

@qstrahl
Copy link
Collaborator

qstrahl commented Aug 18, 2015

I'm going to need to see some more opinions on this before this can be merged.

@amadeus
Copy link
Collaborator

amadeus commented Aug 18, 2015

So, personally I am not a fan of adding these to the syntax file, since I think it will add a lot of mess, and non-standard stuff.

However, what I personally wouldn't mind, is if we put these types of plugin/library specific stuff in special individual files, and then added some logic in the main syntax file to source those files if a particular global variable is set.

Then we could encapsulate that special highlighting separately, and allow new libs to be added if people wanted them without much damage/mess added to the main syntax file. Thoughts?

@qstrahl
Copy link
Collaborator

qstrahl commented Aug 18, 2015

That sounds like the best of both worlds; I'm for it.

On Tue, 18 Aug 2015 16:05 Amadeus Demarzi [email protected] wrote:

So, personally I am not a fan of adding these to the syntax file, since I
think it will add a lot of mess, and non-standard stuff.

However, what I personally wouldn't mind, is if we put these types of
plugin/library specific stuff in special individual files, and then added
some logic in the main syntax file to source those files if a particular
global variable is set.

Then we could encapsulate that special highlighting separately, and allow
new libs to be added if people wanted them without much damage/mess added
to the main syntax file. Thoughts?


Reply to this email directly or view it on GitHub
#288 (comment)
.

@whitneyit
Copy link
Contributor Author

I'm all for having framework/plugin specific annotations

That would then allow more specific highlighting definitions.

For instance the link rule isn't working 100%.

It needs to be able to work with the following:

{@link foo.bar.baz.method Link Title}

Currently the braces and title are not being highlighted

@davidchambers
Copy link
Collaborator

Nice suggestion, @amadeus! I hope it's feasible.

@amadeus
Copy link
Collaborator

amadeus commented Aug 20, 2015

I have an idea for how this could work, let met think about it over this weekend and I'll see if I can get something drawn up.

@whitneyit
Copy link
Contributor Author

I've rebased these changes off of develop. @amadeus is there anything that I can do to help get this PR merged?

@whitneyit
Copy link
Contributor Author

@amadeus did you come up with a way to define custom plugin/library/framework syntax files?

@qstrahl
Copy link
Collaborator

qstrahl commented Feb 22, 2016

@whitneyit Please update this PR and let's see if we can't get it merged in.

@whitneyit
Copy link
Contributor Author

@qstrahl Updated!

amadeus added a commit that referenced this pull request Jun 18, 2016
@amadeus
Copy link
Collaborator

amadeus commented Jun 18, 2016

I have added support for this in #470

@amadeus amadeus closed this Jun 18, 2016
amadeus added a commit that referenced this pull request Jun 18, 2016
amadeus added a commit that referenced this pull request Jun 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants