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

Consider moving some languages (code coloring) out of core #12248

Open
core-ai-bot opened this issue Aug 31, 2021 · 7 comments
Open

Consider moving some languages (code coloring) out of core #12248

core-ai-bot opened this issue Aug 31, 2021 · 7 comments

Comments

@core-ai-bot
Copy link
Member

Issue by peterflynn
Wednesday Feb 27, 2013 at 01:27 GMT
Originally opened as adobe/brackets#2969


In #2844 it was pointed out that some of the languages Brackets has syntax highlighting for out of the box are quite uncommon for modern web developers. Now that it's possible to do so, we could consider moving some languages out into extensions that we don't ship by default.

That only seems worth doing if it has benefits, e.g. improved startup time. We should try removing a bunch of languages from core and timing warm/cold startups to see if it has much effect.

If we do want to remove languages, we'd have to decide three things:

  • Which languages to remove
  • Where to host the extensions (and are they officially supported by the Brackets team? probably wouldn't be much work)
  • What granularity -- one extension per language? Or try to bundle up related language "packs"?

Once we've decided that, the implementation is pretty trivial -- basically a starter bug.

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Wednesday Feb 27, 2013 at 01:31 GMT


Languages we could consider moving out of core: C, C++, C#, Java, Clojure, Lua, SQL, Haxe.

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Wednesday Feb 27, 2013 at 01:35 GMT


There's also some risk here: users might think Brackets flat-out can't support a given language if they open a file and see no highlighting out of the box. (We have that risk already for non-core filetypes, but we'd be adding to it by removing stuff from core). There were two suggestions for dealing with that:
-@DennisKehrig suggested we could have some sort of auto-discovery mechanism built into our future extension registry -- our server would know if any extension exists to support a given file extension and could inform the user if so.
-@gruehle suggseted a simpler idea -- one we could implement now. On first open of an unknown file extension, we just pop a dialog telling the user that an extension may be available and linking to the extensions page.

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Friday Mar 01, 2013 at 20:06 GMT


I just assigned it to you :-) Maybe Peter forgot you were part of the repo's org?

@core-ai-bot
Copy link
Member Author

Comment by DennisKehrig
Friday Mar 01, 2013 at 20:08 GMT


Yay ^^

@core-ai-bot
Copy link
Member Author

Comment by pthiess
Friday Mar 01, 2013 at 20:57 GMT


Dennis' name didn't show up in my list of names, now it does, I love it -:) Thanks for adding him, Peter!

@core-ai-bot
Copy link
Member Author

Comment by njx
Tuesday Apr 01, 2014 at 21:03 GMT


Reviewing - I have a counterproposal: actually keep all the languages in core (and maybe add all the ones we have in codemirror), but just lazy-load the modes, so they aren't loaded until a file that uses that language is open.

To me, low pri

@core-ai-bot
Copy link
Member Author

Comment by nanito2757
Monday Sep 25, 2017 at 02:05 GMT


how to change the language to ide?
to the spanish. thks

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

No branches or pull requests

1 participant