| Re: [eclipse.org-architecture-council] Javascript: a bug that makes me really sad.... |
> On 2015-07-06 21:47, Doug Schaefer wrote: >> For what it¹s worth, I think Michael was talking about *DT not *DK. JDT, >> not JDK. > > Thank you Doug, for clarifying that. This is exactly what I meant: *DT Right, that makes more sense. Though it’s just an acronym for ‘development tool’, which to me is just another name for IDE or smart editor. :-) >> A common AST, at least partial to model symbol references and definitions, >> is indeed necessary for inter-language features. We have had that in CDT >> to handle things between C++ and C (and, yes, they are two different >> languages). We all have lots of experience building IDEs and editors and >> probably different philosophies on how to do it. It¹ll be interesting to >> see if we can find common ground. > > In addition to a common AST, we should also think about a *very* simple > API that allows external tools to contribute to any editor highlights > based on the position in the file (line:column data). *Very* simple means you need to leave out more involving but useful features. E.g. content assist is not simply proposals for some text and offset. There are interesting advanced features Jface provides like "linked editing”. I mean there must be a reason we have ICompletionProposalExtension6 :-) We are currently reimplementing all the IDE services for Xtext such that they can be used with other ‘smart’ editors, and it seems like simple is not always good. Btw. in that sense Xtext also becomes an external tool to other editors, similar to what tern is for JS. > Most "smart editors" > have have APIs to run external tools, once a file is saved and they parse > the output of stdout. The output is simple position information with > some data to be visualized. With such an interface you can > > - run lint tools to find all kinds of errors > - run build tools to visualize build errors and warnings > - run code coverage > - run profile tools > - run unit test > - run tool to get syntax and semantic highlights > - run something like http://ctags.sourceforge.net for code navigation > - run an external tool for code completion or use a generic > code completion tool based on codetrails > - run tools, that automatically format code > - follow standards like editorconfig.org If all these tools only share that they expect the same textual input, than there is a lot of duplicated work (parsing, linking, etc.) going on for each of them. That might work if that work is super cheap, but that is usually not the case. Also you need to think about something like an index (could be external, though), so you can provide proper proposals, navigation and affection detection. That said, I think plain Eclipse does offer hooks to do the things above. Do you mean simple in the sense, that you don’t want to write Java and build a plug-in? Why? This needs to be done only once for every language so many users can simply install the solution. Or should every develop configure the stuff above on her own? Regarding JS and tern, as I think you are mostly concerned about that: I think an editor that can be configured with syntax coloring, is very different to a plug-in that fully leverages the power of tern. For instance sublime seem to do only proposals with tern, while tern itself offers many more interesting features. It is not a simple external tool, it is a full provider of JS-specific tool support. IMHO it is a good idea having a dedicated plug-in that is tailored to leverage exactly that (like Max mentioned) rather than building a generic framework for possibly existing external tools. Cheers, Sven
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail