Skip to content
This repository has been archived by the owner on Sep 7, 2018. It is now read-only.

Support for Dana #12

Closed
AntreasAntoniou opened this issue Sep 18, 2015 · 5 comments
Closed

Support for Dana #12

AntreasAntoniou opened this issue Sep 18, 2015 · 5 comments
Labels

Comments

@AntreasAntoniou
Copy link

Hello guys,

I currently work on a project combining a new programming language with machine learning. I made a syntax highlighter for that language(Dana) in atom that works quite well and I would like to add the .less file in the languages folder of one light as well as the import statement in the one-light-syntax package. I have made those changes locally and all works fine. Is it ok for me to contribute this feature?

@simurai
Copy link
Contributor

simurai commented Sep 19, 2015

Do you mind pasting the content of the less file here?

If all goes well, language specific selectors shouldn't be needed. The ones that are currently in styles/languages are more like temporary "fixes" for Atom's core languages.

@AntreasAntoniou
Copy link
Author

.source.dana {
  .keyword.requirements.dana {
    color: @hue-4;
  }
  .keyword.component.dana {
    color: @hue-3;
  }
  .storage.constructs.dana {
    color: @hue-2;
  }
  .storage.type_2.dana {
    color: @hue-5;
  }
  .keyword.provision.dana{
    color: @hue-3;
  }
}

Yes, I do realise that it shouldn't be necessary. The language pack does work, this modification makes it better visually though for the specific theme

@simurai
Copy link
Contributor

simurai commented Sep 22, 2015

Thanks for the example. Most Atom themes got ported from TextMate and follow its naming conventions.

So using scope selectors like .keyword.requirements, .keyword.component wouldn't work with any other theme. And if more and more languages would add their own selectors, the CSS output would keep growing and slow down performance. Even when some languages never would get used.

But I also understand that just using .keyword.other or so might also not make sense, from a language's perspective and a more nuanced selector is needed.

Hmmmm... lately I've been thinking.. should language packages, next to defining the selectors, also do the styling? Syntax themes would still provide the color variables, but the languages decide how to use those color variables. Like the example you posted, the logic which color gets used for which selector. Could be done like base16 themes. Provide 8 monochrome colors and 8 saturated. Anyways.. that's maybe for a 2.0 release.

In the meantime... how do you feel about forking this theme and publish it as the "optimized for Dana" theme. Then you're free to add any styling you like. Downside is that you would need to maintained it and don't get auto updates.

@AntreasAntoniou
Copy link
Author

Ok then, I will do that as suggested, forking and editing. Thanks for your time on this. Atom is indeed amazing, somebody should make a visual theme creating software so that we can all have a consensus on the way to go about doing things (e.g. I edited atom files directly, others used textmate)

@simurai
Copy link
Contributor

simurai commented Sep 23, 2015

There is a proposal for a refined naming convention. It would add more scopes. Not sure if it would be sufficient in your case.

I edited atom files directly

Me too, I have 2 Atom windows open. One with the theme where I do the editing. And another one with some language examples in "Dev Mode". Then only that window gets updated and I don't mess up my first window. See https://github.com/simurai/language-examples#how-to-use

I'll close this for now, but it's a good example to keep in mind.

@simurai simurai closed this as completed Sep 23, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants