Added Haskell as a language #10844

Merged
merged 1 commit into from Apr 13, 2015

Projects

None yet

4 participants

@VenessaJohansenBarrera
Contributor

Added at the end of the languages.json file so that Haskell will have
syntax highlighting in Brackets.

@VenessaJohansenBarrera VenessaJohansenBarrera Added Haskell as a language
Added at the end of the languages.json file so that Haskell will have
syntax highlighting in Brackets.
3f6ce1b
@peterflynn
Member

@VenessaJohansenBarrera We need you to sign the Brackets contributor agreement (CLA) before we can merge this.

@VenessaJohansenBarrera
Contributor

The agreement has been signed.

Thanks!
On Apr 8, 2015 1:06 AM, "Peter Flynn" notifications@github.com wrote:

@VenessaJohansenBarrera https://github.com/VenessaJohansenBarrera We
need you to sign the Brackets contributor agreement (CLA)
http://dev.brackets.io/brackets-contributor-license-agreement.html
before we can merge this.


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

@abose abose merged commit a693c92 into adobe:master Apr 13, 2015

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
@abose
Contributor
abose commented Apr 13, 2015

validated change, merging. @VenessaJohansenBarrera Thanks!

@busykai
Member
busykai commented Apr 13, 2015

as Brackets is the editor for the web, Haskell should rather not be part of the core. there's a syntax highlighting extension for Haskell, readily available via registry. there are many languages which are intentionally not part of Brackets, but still available as extensions. why Haskell has been made an exception?

@abose
Contributor
abose commented Apr 14, 2015

This change only brings in the file extension awareness in brackets and very basic comment block awareness for haskell, similar to the way we have basic support for c/c++/java... which are not primarily 'web' langs. Full blown support is not part of brackets as said.

@busykai
Member
busykai commented Apr 20, 2015

@abose, I'm sorry for being stubborn, but this deserves some more discussion. I am pretty sure I understand what this PR does (exactly what the corresponding would do). We also could have support for Cobol, Pascal, Fortran etc., but we did not add these before. I would understand including these if there were no extensibility, but I'd much rather add support for these via extensions. Now, that's my personal preferences... I guess from the product standpoint, we just have to be consistent add all of them or only those which are relevant to web development. Strong focus on web is what makes Brackets so great. Having these irrelevant languages floating around would only create false expectations on the customer side and steals time from development.

Usability-wise, we have a drop-down box to pick a language in the editor status bar. I'd rather not contaminate that list with arbitrary languages (it's long enough already). Those who need support for extra languages have extensions at their disposal.

Just my couple of cents.

@abose
Contributor
abose commented Apr 20, 2015

I see your point @busykai , and now that i think of it , i agree with you. Haskell is still an obscure language (compared to c/c++/etc.. in our language dropdown), so supporting that is best left to the extensions as they could give in much more support for those languages than the basic support. If no one objects, i could revert the commit by wednesday.

@abose abose was assigned by rroshan1 Apr 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment